OpenVZ Forum


Home » International » Russian » Как там дела с 2.6.18-8.el5 028stab034.1 ?
Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13867] Thu, 07 June 2007 03:47 Go to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Мож для особо нетерпеливых доступен CVS разработчиков ?

А то тут занимаюсь устаревшим el5-028.027. Ситуация такая. Как dom0 ядро -- претензий нет. Запускаются и domU, и VE.

А вот если пытаюсь его использовать в rPath вместо родного domU-ядра, то
1) заметно медленнее грузится
2) не выскакивает логин. То есть загрузка сервисов прошла и все. Хотя удаленно можно подключиться по ssh.

Поэтому создавать внутри domU VE я еще не пробовал. Хочется понять -- где проблема. И интересно узнать о прогрессе el5-028.034 относительно Xen.
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13902 is a reply to message #13867] Thu, 07 June 2007 10:52 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

текущий snapshot 034 патча может быть скачан отсюда:
http://download.openvz.org/~dev/patch-028stab034-core
этот патч на ядро EL5-8.1.4.
не тестировался мной еще вообще (иммейте это ввиду).
сейчас я собираю 034 ядро и отдаю на тестинг.

С CVS вопрос пока не решен, т.к. помимо чисто технических деталей - есть и полу-политические, например, как быть с security fix'ами у которых есть embargo date?


http://static.openvz.org/userbars/openvz-developer.png

[Updated on: Thu, 07 June 2007 10:53]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13920 is a reply to message #13902] Thu, 07 June 2007 23:36 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Ядро собралось, но запускаться отказывается. Как dom0 (без PAE), так и domU. Вот что говорит domU:

Freeing SMP alternatives: 16k freed 
Page beancounter hash is 16384 entries. 
Brought up 1 CPUs 
checking if image is initramfs... it is
Freeing initrd memory: 3122k freed
list_add corruption. prev->next should be c068bd6c, but was c0ad987c
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:31!
invalid opcode: 0000 [#1]
SMP
last sysfs file:
Modules linked in:
CPU:    0, VCPU: 0.0
EIP:    0061:[<c04d5e14>]    Not tainted VLI
EFLAGS: 00010046   (2.6.18-fan_rh5_openvz_xen-028.034 #1)
EIP is at __list_add+0x3c/0x58
eax: 00000048   ebx: c068bd6c   ecx: c0ac5e44   edx: c0ac5e44
esi: c0ad926c   edi: c0ad8c5c   ebp: c0ad8660   esp: c0ac5e40
ds: 007b   es: 007b   ss: e021
Process swapper (pid: 1, veid: 0, ti=c0ac4000 task=c0ad9890 task.ti=c0ac4000)
Stack: c0646b70 c068bd6c c0ad987c 00000000 c0adee08 c0ade8c8 c041bcf9 00000004
       00000004 c0ac5ee0 00000000 00800711 c0ac5ee0 c0ae04a4 fffffff5 00800711
       c041bfd1 00000000 00000000 00000000 c0ae04a4 00000000 00000000 c068d080
 Call Trace:
 [<c041bcf9>] copy_process+0xc66/0xe77
 [<c041bfd1>] do_fork_pid+0x6e/0x16b
 [<c04543c4>] buffered_rmqueue+0x105/0x122
 [<c0430d2b>] kthread+0x0/0x9f
 [<c041c0f2>] do_fork+0x13/0x17
 [<c0402c72>] kernel_thread+0xa3/0xad
 [<c0430d2b>] kthread+0x0/0x9f
 [<c0402bc4>] kernel_thread_helper+0x0/0xb
 [<c0430ddf>] keventd_create_kthread+0x15/0x4f
 [<c0430e95>] kthread_create+0x7c/0xba
 [<c0430dca>] keventd_create_kthread+0x0/0x4f
 [<c042dbde>] worker_thread+0x0/0x138
 [<c042dea2>] create_workqueue_thread+0x79/0x90
 [<c042dbde>] worker_thread+0x0/0x138
 [<c042df5b>] __create_workqueue+0xa2/0xe9
 [<c0402067>] init+0x0/0x141
 [<c042e218>] init_workqueues+0x1b/0x33
 [<c070e9b9>] do_basic_setup+0xf/0x23
              init+0x51/0x14


Кстати, я пробовал собрать el5-028.027 без openvz, ибо не выдавался логин в domU (но sshd в domU работал). Так без openvz ядро в domU тоже не грузилось и говорило про invalid opcode 000
Этого я не понимаю... Собрать что ль чистое EL5-8.1.4
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13928 is a reply to message #13902] Fri, 08 June 2007 04:17 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Собрал чистое ядро EL5-8.1.4 Оно нормально загрузилось как dom0-ядро. Как domU-ядро в том образе centos5, что я скачал из интернет, ведет себя так же, как и rh5_openvz_028.027. То есть проблема в security для console (при входе под непривелегированным пользователем ругается на отсутствие полномочий для /dev/null). Надо будет попробовать собрать rh5_openvz-028.027 с конфигом от ядра rPath (или просто убрать для начала selinux из конфига)

Создавать domU под Virt-Manager (даже находясь в Scientific Linux 5) я не научился -- все попытки у меня заканчиваются ошибками

Мож кто подскажет, у кого это получилось (под RHEL5-подобным дистром), какие URL надо подставлять при вопросе о дистрибутиве и KS?

PS: да, после чтения документации по XEN от RH, понял, что при NFS-доступе к дистру, можно подставлять путь к ISO, вместо смонтированного содержимого ISO.

Сейчас еще буду пробовать в SL5 самому создать domU.
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13929 is a reply to message #13928] Fri, 08 June 2007 06:14 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Создать свой domU из Virt-Manager на этот раз получилось. В предыдущие разы я пытался указать URL из интернет. На этот раз я сделал доступным у себя по FTP содержимое установочного диска CentOS5 и немного уменьшил размер максимальной памяти для domU (212МБ, всего у меня 512). 256Мб для domU не удается выделить, так как существует ограничение на минимальную память для dom0 (248?), плюс около 48Мб отъедает сам Xen-монитор.

PS: при указании завышенного RAM для domU (которое нельзя выделить), выдается сообщение о невозможности создать виртуальную машину
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13934 is a reply to message #13920] Fri, 08 June 2007 07:45 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

сейчас чиним...

http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13937 is a reply to message #13920] Fri, 08 June 2007 08:05 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

первая часть фиксится убиранием всех init_v0_process() из init_ve_system(). теперь проблема с самими VE.
Я вам выдам полный патчик через какое-то время когда буду готов ставить ядро на билд.


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13938 is a reply to message #13934] Fri, 08 June 2007 08:25 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

patch 1:
--- ./kernel/ve/veowner.c.ve2505	2007-06-07 12:43:15.000000000 +0400
+++ ./kernel/ve/veowner.c	2007-06-08 12:21:09.000000000 +0400
@@ -237,20 +237,6 @@ void init_ve_system(void)
 
 	ve = get_ve0();
 
-	/* Don't forget about idle tasks */
-	write_lock_irqsave(&tasklist_lock, flags);
-	for (i = 0; i < NR_CPUS; i++) {
-		tsk = idle_task(i);
-		if (tsk == NULL)
-			continue;
-
-		prepare_ve0_process(tsk);
-	}
-	do_each_thread_all(p, tsk) {
-		prepare_ve0_process(tsk);
-	} while_each_thread_all(p, tsk);
-	write_unlock_irqrestore(&tasklist_lock, flags);
-
 	init_entry = child_reaper;
 	ve->init_entry = init_entry;
 	/* if ve_move_task to VE0 (e.g. in cpt code)	*


patch2:
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -996,12 +996,12 @@ fail:
 
 void rpc_run_child(struct rpc_task *task, struct rpc_task *child, rpc_action func)
 {
-	rpc_set_active(task);
+	rpc_set_active(child);
 
 	spin_lock_bh(&childq.lock);
 	/* N.B. Is it possible for the child to have already finished? */
 	__rpc_sleep_on(&childq, task, func, NULL);
-	rpc_make_runnable(task);
+	rpc_make_runnable(child);
 	spin_unlock_bh(&childq.lock);
 }
 



http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13939 is a reply to message #13920] Fri, 08 June 2007 08:32 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

fixed patch-028stab034-core uploaded to the same URL


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13992 is a reply to message #13939] Sat, 09 June 2007 04:11 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

С исправленным патчем domU-ядро работает. А вот dom0-ядро лично у меня перегружается на попытке определить тип монитора через DDC
ddcxinfo-knoppix -monitor

Сейчас выкину это из загрузочных скриптов и попробую снова загрузиться
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #13995 is a reply to message #13992] Sat, 09 June 2007 07:40 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

ok. чуть-чуть продвинулись. Не помню, мне Женя что-то говорил что у него и родной RHEL5 в Dom0 не работает...


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14009 is a reply to message #13995] Sun, 10 June 2007 05:31 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Нет, родной работает. И полученный 028.034 dom0 работает. Только падает на ddcxinfo-knoppix. Без ddcxinfo-knoppix вроде все нормально. 028.027 -- не падает. С добавленными патчами openvz до 028.033 -- не падает. Похоже проблема с добавленными патчами, специфичными для rhel5. Может что-то для работы с большой памятью или обработкой bios-вызовов (ddcxinfo - он пытается пользовать vesa-вызова, как я понимаю)

Как бы узнать список патчей от команды openvz, которые специфичны для ядра rhel5 (отсутствуют в чистом openvz)
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14011 is a reply to message #14009] Sun, 10 June 2007 20:33 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Найдите два отличия... Вот возникли вопросы по поводу обсуждаемого rhel5-028.034.
Первый: arch/i386/kernel/process.c (строка 322). Куда делись строки

extern void kernel_thread_helper(void);
EXPORT_SYMBOL(kernel_thread_helper);
+__asm__(".section .text\n"
+        ".align 4\n"
+        ".global kernel_thread_helper\n"
+        "kernel_thread_helper:\n\t"
+        "movl %edx,%eax\n\t"
+        "pushl %edx\n\t"
+        "call *%ebx\n\t"
+        "pushl %eax\n\t"
+        "call do_exit\n"
+        ".previous");


В нормальном openvz в этом файле они присутствуют, и в данном варианте в файле process-xen.c тоже присутствуют (только строчка .global там есть?)

Может это несущественно, но следующий patch тоже отсутствует
diff -urN linux-2.6.18-openvzelx-028.030-orig/arch/i386/kernel/traps-xen.c linux-2.6.18-openvzelx-028.030/arch/i386/kernel/t
--- linux-2.6.18-openvzelx-028.030-orig/arch/i386/kernel/traps-xen.c    2007-04-24 18:19:31.000000000 +0400
+++ linux-2.6.18-openvzelx-028.030/arch/i386/kernel/traps-xen.c 2007-04-24 18:20:05.000000000 +0400
@@ -748,6 +748,14 @@

 static DEFINE_SPINLOCK(nmi_print_lock);

+#ifdef CONFIG_SMP
+int __attribute__((weak))
+smp_nmi_call_function(smp_nmi_function func, void *info, int wait)
+{
+       return 0;
+}
+#endif
+
 void die_nmi (struct pt_regs *regs, const char *msg)
 {
        if (notify_die(DIE_NMIWATCHDOG, msg, regs, 0, 2, SIGINT) ==


По сравнению с traps.c еще отсутствует строчка
void __attribute__((weak)) smp_show_regs(struct pt_regs *regs, void *info) {} перед этим

Указанные патчи для файлов *-xen.c делались по аналогии с патчами openvz для файлов *.c. То есть если openvz вносит изменение в файл, для которого существует xen-аналог (дубль), то логично изменять также и этот дубль.

PS: Указанные несоответствия обнаружились при попытке наложить на rhel5-028.027 patch 027to034 из GIT (хотелось найти различие между таким ядром и тем, что получается при наложении обсуждаемого патча)

Рекомендуемое дополнение к 028.034: http://89.19.167.91/fantoo/patch-028stab034-core.ver02.addon

Однако с проблемой ddcxinfo-knoppix это не помогло. Буду искать отличия 028.027+027to034 от 028.034

[Updated on: Sun, 10 June 2007 22:31]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14014 is a reply to message #14011] Mon, 11 June 2007 04:12 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

разница между 028.027+027to034 и обсуждаемым 028.034 получилась довольно большой -- 200 КЬайт.

http://89.19.167.91/fantoo/028.034-git.patch

Что бросилось в глаза:
diff -urN linux-2.6.18-028.034.git/net/sunrpc/clnt.c linux-2.6.18-028.034/net/sunrpc/clnt.c
--- linux-2.6.18-028.034.git/net/sunrpc/clnt.c  2007-06-11 03:57:23.000000000 +0400
+++ linux-2.6.18-028.034/net/sunrpc/clnt.c      2007-06-11 07:26:47.000000000 +0400
@@ -299,9 +299,7 @@
        new->cl_autobind = 0;
        new->cl_oneshot = 0;
        new->cl_dead = 0;
-       new->cl_broken = 0;
-       if (!IS_ERR(new->cl_dentry))
-               dget(new->cl_dentry);
+       new->cl_broken = 0;
        rpc_init_rtt(&new->cl_rtt_default, clnt->cl_xprt->timeout.to_initval);
        if (new->cl_auth)
                atomic_inc(&new->cl_auth->au_count);


Это отсутствие в rhel5-варианте проверки на !IS_ERR
Дальше не изучал.

Относительно проблемы -- это наличие в rhel5-варианте изменений для arch/i386/kernel/vm86.c Именно эти изменения могли привести к перезагрузке dom0 по ddcxinfo-knoppix
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14015 is a reply to message #14014] Mon, 11 June 2007 05:09 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Просьба: проанализировать изменения в файле arch/i386/kernel/vm86.c на предмет правильности работы в dom0. Ибо откат этих изменений позволил нормально отработать программе
 ddcxinfo-knoppix  -monitor 


Ну и учесть рекомендуемый патч плюс замечание по net/sunrpc/clnt.c (отсутствует if (!IS_ERR(new->cl_dentry)))

[Updated on: Mon, 11 June 2007 05:12]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14027 is a reply to message #14015] Tue, 12 June 2007 03:37 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

С вот таким патчем для arch/i386/kernel/vm86.c тоже все работает (отличие -- добавили #else для случая CONFIG_X86_NO_TSS=y и старые команды для этого случая)
--- arch/i386/kernel/vm86.c.old 2007-06-12 06:05:00.000000000 +0400 
+++ arch/i386/kernel/vm86.c     2007-06-12 06:11:17.000000000 +0400 
@@ -125,11 +125,15 @@ 
        } 
  
 #ifndef CONFIG_X86_NO_TSS 
-       tss = &per_cpu(init_tss, get_cpu()); 
+       tss = __get_cpu_tss(get_cpu());
 #endif
        current->thread.esp0 = current->thread.saved_esp0;
        current->thread.sysenter_cs = __KERNEL_CS;
+#ifndef CONFIG_X86_NO_TSS
+       load_virtual_esp0(tss, current);
+#else
        load_esp0(tss, &current->thread);
+#endif
        current->thread.saved_esp0 = 0;
 #ifndef CONFIG_X86_NO_TSS
        put_cpu();
@@ -305,14 +309,17 @@
        savesegment(gs, tsk->thread.saved_gs);

 #ifndef CONFIG_X86_NO_TSS
-       tss = &per_cpu(init_tss, get_cpu());
+       tss = __get_cpu_tss(get_cpu());
 #endif
        tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0;
        if (cpu_has_sep)
                tsk->thread.sysenter_cs = 0;
-       load_esp0(tss, &tsk->thread);
+
 #ifndef CONFIG_X86_NO_TSS
+       load_virtual_esp0(tss, tsk);
        put_cpu();
+#else
+       load_esp0(tss, &tsk->thread);
 #endif

        tsk->thread.screen_bitmap = info->screen_bitmap;

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14035 is a reply to message #14015] Tue, 12 June 2007 14:55 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Только что-то я не понимаю... Грузим в domU родное rhel5 ядро. Имеем SELinux и никакой ругани о установлении 4Gb segment limit. Берем тот же config и собираем rhel5_openvz_028.034. Никакого SELinux и ругань о 4Gb выравнивании почти для всех программ.

С SELinux понятно -- если VE, то никаких SELinux. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект.

Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для

[Updated on: Tue, 12 June 2007 22:38]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14041 is a reply to message #14011] Wed, 13 June 2007 07:46 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

kernel_thread_helper есть в arch/i386/kernel/entry.S:
ENTRY(kernel_thread_helper)
        pushl $0                # fake return address for unwinder
        CFI_STARTPROC
        movl %edx,%eax
        push %edx
        CFI_ADJUST_CFA_OFFSET 4
        call *%ebx
        push %eax
        CFI_ADJUST_CFA_OFFSET 4
        call do_exit
        CFI_ENDPROC
ENDPROC(kernel_thread_helper)


в этом смысле разницы я не вижу, в i386 он в entry.S, в i386-xen в process-xen.c

smp_nmi_call_function мы не стали бэкпортить так как это debug, который в xen нафиг не нужен (и не скорее всего в xen не работает, т.к. NMI IPI - он вряд ли умеет обрабатывать). меньше изменений - легче жить.


http://static.openvz.org/userbars/openvz-developer.png

[Updated on: Wed, 13 June 2007 07:46]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14042 is a reply to message #14027] Wed, 13 June 2007 08:30 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

ouch... точно!

я правда не понял к какой версии это патч, т.к. замена:
 #ifndef CONFIG_X86_NO_TSS 
-       tss = &per_cpu(init_tss, get_cpu()); 
+       tss = __get_cpu_tss(get_cpu());
 #endif

и в 034 и 035 уже есть.

в результате я закоммитил в 036 вот такой патч:
--- ./arch/i386/kernel/vm86.c.ve2555    2007-06-08 19:38:56.000000000 +0400
+++ ./arch/i386/kernel/vm86.c   2007-06-13 12:26:23.000000000 +0400
@@ -129,9 +129,7 @@ struct pt_regs * fastcall save_v86_state
 #endif
        current->thread.esp0 = current->thread.saved_esp0;
        current->thread.sysenter_cs = __KERNEL_CS;
-#ifndef CONFIG_X86_NO_TSS
        load_virtual_esp0(tss, current);
-#endif
        current->thread.saved_esp0 = 0;
 #ifndef CONFIG_X86_NO_TSS
        put_cpu();
@@ -313,8 +311,8 @@ static void do_sys_vm86(struct kernel_vm
        if (cpu_has_sep)
                tsk->thread.sysenter_cs = 0;

-#ifndef CONFIG_X86_NO_TSS
        load_virtual_esp0(tss, tsk);
+#ifndef CONFIG_X86_NO_TSS
        put_cpu();
 #endif



NOTE: load_virtal_esp0 и load_esp0 это одно и тоже в случае ядра Xen, так что #else не нужны.

Огромное спасибо!


http://static.openvz.org/userbars/openvz-developer.png

[Updated on: Wed, 13 June 2007 08:30]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14043 is a reply to message #14035] Wed, 13 June 2007 08:35 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

seyko2 wrote on Tue, 12 June 2007 18:55

Только что-то я не понимаю... Грузим в domU родное rhel5 ядро. Имеем SELinux и никакой ругани о установлении 4Gb segment limit. Берем тот же config и собираем rhel5_openvz_028.034. Никакого SELinux и ругань о 4Gb выравнивании почти для всех программ.


можно поконкретнее что за ругань? какое сообщение?

Quote:


С SELinux понятно -- если VE, то никаких SELinux. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект.



давай-те его чинить Smile

Quote:


Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для


нет, vm86.c менялся не из-за ругани, а в соответствие с 4gb split'ом. Когда эта фича включена, то TSS, GDT, LDT и прочее начинает управляться иным образом, поэтому и патч такой гигантский.


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14045 is a reply to message #14014] Wed, 13 June 2007 08:44 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

cl_dentry проверяется позже, так что проблемы нет.


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14063 is a reply to message #14042] Wed, 13 June 2007 20:28 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Осталось только пропатчить include/asm/march-xen/asm/processor.h на предмет указанных define. Ибо хавается он, а не include/asm/processor.h

 diff -u include/asm/mach-xen/asm/processor.h.orig  include/asm/mach-xen/asm/processor.h
--- include/asm/mach-xen/asm/processor.h.orig   2007-06-14 00:15:55.000000000 +0400
+++ include/asm/mach-xen/asm/processor.h        2007-06-14 00:16:07.000000000 +0400
@@ -569,6 +569,32 @@
  */
 extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
+#ifdef CONFIG_X86_HIGH_ENTRY
+#define virtual_esp0(task) \
+       ((unsigned long)((task)->thread_info->virtual_stack + ((task)->thread.esp0 - (unsigned long)(task)->thread_info->real_stack)))
+#define load_virtual_esp0(tss, task)                                   \
+       do {                                                            \
+               tss->esp0 = virtual_esp0(task);                         \
+               if (likely(cpu_has_sep) && unlikely(tss->ss1 != (task)->thread.sysenter_cs)) {  \
+                       tss->ss1 = (task)->thread.sysenter_cs;          \
+                       wrmsr(MSR_IA32_SYSENTER_CS,                     \
+                               (task)->thread.sysenter_cs, 0);         \
+               }                                                       \
+       } while (0)
+
+#else
+
+#define virtual_esp0(task) ((task)->thread.esp0)
+#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread) 
+
+#endif
+
+#ifndef CONFIG_XEN
+#define __get_cpu_tss(cpu) (init_tss + (cpu))
+#else
+#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu))
+#endif
+
 extern unsigned long thread_saved_pc(struct task_struct *tsk);
 void show_trace(struct task_struct *task, struct pt_regs *regs, unsigned long *stack);


И что конкретно делать для остальных файлов в этом каталоге? openvz пропатчил кучу файлов в include/asm, аналоги которых есть в include/asm/mach-xen/asm
  desc.h
  fixmap.h
  highmem.h
  kmap_types.h
  mmu.h
  mmu_context.h
  page.h
  pgtable.h
  processor.h
  system.h
  tlbflush.h


Попытка пропатчить эти файлы по аналогии -- провалилась. Ибо тогда вылезает куча проблем с компиляцией. Получается, что для XEN-архитектуры BIG-mem patch применился лишь частично и работать не будет.

Можно поиметь этот BIG-mem patch в отдельном виде?

Да, а ругается в domU файл arch/i386/kernel/fixup.c Собрал сам на всякий случай ядро rhel5 (для проверки особенностей сборки). Оно, как и оригинальное ядро от RH, не ругается...

[Updated on: Thu, 14 June 2007 00:21]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14086 is a reply to message #14063] Thu, 14 June 2007 11:25 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

seyko2 wrote on Thu, 14 June 2007 00:28

Осталось только пропатчить include/asm/march-xen/asm/processor.h на предмет указанных define. Ибо хавается он, а не include/asm/processor.h




блин, облажался... %( все время забываю что они накопировали код :/

Quote:



 diff -u include/asm/mach-xen/asm/processor.h.orig  include/asm/mach-xen/asm/processor.h
--- include/asm/mach-xen/asm/processor.h.orig   2007-06-14 00:15:55.000000000 +0400
+++ include/asm/mach-xen/asm/processor.h        2007-06-14 00:16:07.000000000 +0400
@@ -569,6 +569,32 @@
  */
 extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
+#ifdef CONFIG_X86_HIGH_ENTRY
+#define virtual_esp0(task) \
+       ((unsigned long)((task)->thread_info->virtual_stack + ((task)->thread.esp0 - (unsigned long)(task)->thread_info->real_stack)))
+#define load_virtual_esp0(tss, task)                                   \
+       do {                                                            \
+               tss->esp0 = virtual_esp0(task);                         \
+               if (likely(cpu_has_sep) && unlikely(tss->ss1 != (task)->thread.sysenter_cs)) {  \
+                       tss->ss1 = (task)->thread.sysenter_cs;          \
+                       wrmsr(MSR_IA32_SYSENTER_CS,                     \
+                               (task)->thread.sysenter_cs, 0);         \
+               }                                                       \
+       } while (0)
+
+#else
+
+#define virtual_esp0(task) ((task)->thread.esp0)
+#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread) 
+
+#endif
+
+#ifndef CONFIG_XEN
+#define __get_cpu_tss(cpu) (init_tss + (cpu))
+#else
+#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu))
+#endif
+
 extern unsigned long thread_saved_pc(struct task_struct *tsk);
 void show_trace(struct task_struct *task, struct pt_regs *regs, unsigned long *stack);





А как Вам такой вариант:

--- ./arch/i386/Kconfig.ve9992  2007-06-08 19:39:07.000000000 +0400
+++ ./arch/i386/Kconfig 2007-06-14 14:58:27.000000000 +0400
@@ -223,6 +223,7 @@ source "arch/i386/Kconfig.cpu"

 config X86_4G
        bool "4 GB kernel-space and 4 GB user-space virtual memory support"
+       depends on !X86_XEN
        help
           This option is only useful for systems that have more than 1 GB
           of RAM.
--- ./include/asm-i386/mach-xen/asm/processor.h.ve9992  2007-06-08 19:39:07.000000000 +0400
+++ ./include/asm-i386/mach-xen/asm/processor.h 2007-06-14 15:04:30.000000000 +0400
@@ -535,6 +535,9 @@ static inline void __load_esp0(struct ts
        HYPERVISOR_stack_switch(__KERNEL_DS, (thread)->esp0)
 #endif

+#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread)
+#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu))
+
 #define start_thread(regs, new_eip, new_esp) do {              \
        __asm__("movl %0,%%fs ; movl %0,%%gs": :"r" (0));       \
        set_fs(USER_DS);                                        \


Quote:


И что конкретно делать для остальных файлов в этом каталоге? openvz пропатчил кучу файлов в include/asm, аналоги которых есть в include/asm/mach-xen/asm
  desc.h
  fixmap.h
  highmem.h
  kmap_types.h
  mmu.h
  mmu_context.h
  page.h
  pgtable.h
  processor.h
  system.h
  tlbflush.h


Попытка пропатчить эти файлы по аналогии -- провалилась. Ибо тогда вылезает куча проблем с компиляцией. Получается, что для XEN-архитектуры BIG-mem patch применился лишь частично и работать не будет.



мое IMHO: ничего не делать. в Xen'е нафиг не нужен 4/4GB split, и боюсь он там просто напросто и работать-то не будет без серьезных усилий, потому как вещь это сильно завязанная на архитектуру, а Xen как раз меняет по сути архитектурный код. А самое главное в этой фичи особого смысла нет для Xen'а - она нужна чтобы запускать как можно больше VE на i386.

Quote:


Можно поиметь этот BIG-mem patch в отдельном виде?



Да, конечно.
http://download.openvz.org/~dev/patches-035-ovz/
все патчи начинающиеся на diff-arch-4g

Quote:


Да, а ругается в domU файл arch/i386/kernel/fixup.c Собрал сам на всякий случай ядро rhel5 (для проверки особенностей сборки). Оно, как и оригинальное ядро от RH, не ругается...



Вопрос: а оно ругается если не стартовать VE?
На какие процессы хотя бы жалуется?
Насколь я понимаю из описания оно должно жаловаться на glibc у которой TLS support собран как-то по старому. Наверняка, в каких-то VE как раз это и происходит. На хосте по идее все должно быть пучком.


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14091 is a reply to message #14086] Thu, 14 June 2007 14:29 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

За патчи спасибо!

Про ругань: запускаем только domU (centos5) с нашим ядром и почти на все процессы идут сообщения о 4gb seg fixup (по 4 тысячи на процесс). Тот же centos5 с родным ядром (собранным из исходников по той же технологии) не ругается. VE в domU пока даже не пахнет (не пытаемся пока запускать). Ругань -- обеспечивает Xen-монитор (xen/arch/x86/x86_32/seg_fixup.c) по запросу domU-ядра, когда он выполняет фиксацию размеров сегментов (он вызывает как call-back функцию из arch/i386/kernel/fixup.c). В openvz-ядре с размером сегментов что-то не так (с прописыванием их размеров), ибо меняется только ядро (родное или openvz). glibc здесь не меняется и не виновата в выдаче сообщений.

Можно конечно подавить выдачу предупреждений (в Xen-мониторе не вызывать callback-функцию), но это как-то не кузяво.

PS: по имеющемуся опыту эксплуатации rhel5-openvz-ядро -- наиболее стабильное 2.6.18-ядро под Xen. Пытался несколько раз работать под Xen-3.1-ядром (с openvz и без) и все как-то неудачно -- ядро часто через некоторое время начинало тормозить и глюкавить.

[Updated on: Thu, 14 June 2007 14:44]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14092 is a reply to message #14091] Thu, 14 June 2007 14:34 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

вероятно опять-таки виноват 4GB split, но я пока не понимаю как... :/

http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14103 is a reply to message #14091] Thu, 14 June 2007 18:42 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Кстати, буду премного благодерн если Вы найдете время и силы как-нибудь посмотреть на эту wiki страничку:
https://wiki.openvz.org/How_to_use_OpenVZ_as_a_XEN_guest_OS_ %28for_x86_platform%29

Предупреждаю сразу, она совсем не кузява :/, т.к. писал человек не очень опытный. Поэтому буду очень благодарен за помощь в ее доведении до ума.


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14107 is a reply to message #14092] Thu, 14 June 2007 19:14 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Вот как выглядят сообщения
EXT3-fs: mounted filesystem with ordered data mode.
4gb seg fixup, process init (pid 1), cs:ip 73:00a2c760
4gb seg fixup, process init (pid 1), cs:ip 73:00a2c760
4gb seg fixup, process init (pid 1), cs:ip 73:00aa1b69
4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd5c
4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd6a
4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd5c
4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd6a
4gb seg fixup, process init (pid 1), cs:ip 73:009eab7b
4gb seg fixup, process init (pid 1), cs:ip 73:009eab64
4gb seg fixup, process init (pid 1), cs:ip 73:00a358b5
printk: 109680 messages suppressed.
4gb seg fixup, process hwclock (pid 276), cs:ip 73:0052c480
4gb seg fixup, process hwclock (pid 276), cs:ip 73:490ce6f6
4gb seg fixup, process hwclock (pid 276), cs:ip 73:005b00c8
printk: 567140 messages suppressed.
4gb seg fixup, process S14nfslock (pid 2477), cs:ip 73:0090a85e
printk: 705301 messages suppressed.
4gb seg fixup, process modprobe (pid 2671), cs:ip 73:00bd7811
printk: 555473 messages suppressed.
4gb seg fixup, process S90xfs (pid 2823), cs:ip 73:0071185e


А вот openvz-ядро без 4-gb-патчей:
EXT3-fs: mounted filesystem with ordered data mode.
4gb seg fixup, process init (pid 1), cs:ip 73:00cbf760
4gb seg fixup, process init (pid 1), cs:ip 73:00d34b69
4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c
4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d6a
4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c
4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c
4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d6a
4gb seg fixup, process init (pid 1), cs:ip 73:00c7db7b
4gb seg fixup, process init (pid 1), cs:ip 73:00c7db64
4gb seg fixup, process init (pid 1), cs:ip 73:00cc88b5
printk: 109695 messages suppressed.
4gb seg fixup, process hwclock (pid 276), cs:ip 73:00506480
4gb seg fixup, process hwclock (pid 276), cs:ip 73:490ce6f6
4gb seg fixup, process hwclock (pid 276), cs:ip 73:0058a0c8


Сообщения хоть и со смещением, но в тех же местах. Получается, что 4-gb-патч не виноват

[Updated on: Thu, 14 June 2007 19:29]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14112 is a reply to message #14107] Fri, 15 June 2007 05:51 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

А вообще это сообщение выдается при выполнеии инструкции в пользовательской программе, которая обращается к памяти данных с использованием GS: и прерывается по защите памяти, если смещение велико и попадает в область памяти, занимаемой Xen-монитором (реальный 4Gb сегмент). Ками-то образом программы получают от openvz-ядра сегмент для данных, который не урезан с учетом Xen.
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14119 is a reply to message #14103] Fri, 15 June 2007 06:53 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Про Wiki-страничку...
Странно... xen-3.1.0 использует 2.6.18 ядро, а не 2.6.16 Вдобавок лучше все же описать установку стандартного xen-монитора и ядра dom0 из дистрибутива, а не с сайта xensource (хотя последнее описание для меня было достаточно полезно). Все же RHEL5 долго вылизывала именно свою версию dom0.

В описании пунктов меню для grub лучше опустить указание root(hd0,1). Это плохая практика (ухудшает переносимость на другие диски). Все прекрасно грузится и без этой строчки.

Про tls лучше опустить -- в RHEL5 с этим все в ажуре. Или указать конкретно, что совет -- для дистров с glibc-2.3

Какой openvz-xen мы устанавливаем? dom0? domU? Надо бы четче указать.

Quote:

OpenVZ XenLinux kernel is able to work also in Dom0. It can be tested just by updating /etc/grub.conf on the hardware node. But in this case it will be impossible to start DomUs. It is a known bug and it is related not to OpenVZ, but to RHEL5 kernel.


Странно... А у меня openvz в dom0 работает, запускает domU и VE. Вот в domU оно ругается на 4gb seg fixup. Но работает. Другие ядра для domU (родные) работают и не ругаются. Так какой-же xen использовали при написании Wiki? 3.1? И при использовании xen-3.1 openvz-028.34 в domU не вызывает ругани про 4gb seg? Очень интересно. Сейчас проверю...

PS: да, а машина то у нас при написании Wiki была обычная x86-32 или x86-64? А то ругань то только в x86-32 происходит.
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14122 is a reply to message #14119] Fri, 15 June 2007 07:36 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

С xen-3.1 тоже ругается. Вполне возможно это из-за того, что у меня в конфигурации памяти выбрано 4Gb, а не 64Gb (то бишь не PAE) и не default. Но ядро от RHEL5 в той же конфигурации в domU не ругается...

Допускаю, что xen-3.1 для PAE как-то оптимизировали и он уже не ругается на 4Gb seg fixup при использовании в domU openvz-xen-028.034 Это верно?

PS: сейчас собираю ядро с default для памяти (то бишь < 1Gb). По идее в этом случае ругаться на 4gb fixup тоже не должно.
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14131 is a reply to message #14107] Fri, 15 June 2007 10:02 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

0x73 это селектор __USER_CS
#define __USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)

давайте тогда сделаем objdump -dr /sbin/init и hwclock и посмотрим что за инструкция по указанным IP адресам.

Хмм... 4GB split был первым кандидатом...
а я правильно понимаю, что на 027 ядре этого не было?
не вижу ни одного патча из этого списка что могли бы повлиять:

diff list-028stab027 list-028stab037

3c3,13
< # Based on 2.6.18-8.1.1.el5 kernel
---
> # Based on 2.6.18-8.1.4.el5 kernel
>
> # --------------------------------------------
> # 4gb split
> diff-arch-4gb-20070409-2
> diff-arch-4gb-cr4-20070410            # to LKML
> diff-arch-x86-ioremap-guard-page-fix-20070419
> diff-arch-4gb-ldt-irqs-20070515
> diff-arch-4gb-xen-20070523
> diff-arch-4gb-xen-cleanup-20070528
> diff-arch-4gb-xen-b-20070613
23a34
> namespaces-utsname-xen.patch
46a58
> io-accounting-menuconfig.patch
71a84
> diff-ms-cpufreq-centrino-20070426
78a92,94
> diff-ms-cfq-allow-merge-b-20070424
> diff-ms-cfq-allow-merge-c-20070507
> diff-ms-cfq-rm-redundant-find-next-req-20070509
91a108,110
> diff-ms-ext3-iread-brelse-20070601
> diff-ms-ext3-orhpan-list-corruption-20070531
> diff-ms-ext3-orhpan-list-corruption-b-20070603
93a113,147
> diff-ms-lockdep-neighbour-table-class-20070409
> diff-ms-bridge-unaligned-access-20070411 # send to LKML
> diff-ms-stopmachine-msleep-20070411   # send to LKML
> diff-ms-elf-retval-20070420           # send to LKML
> diff-ms-loop-dont-complete-lo-bh-done-20070418
> # diff-ms-fib-netlink-lookup-recursion-20070425
> # diff-ms-fib-netlink-lookup-recursion-b-20070425
> # `- linux-2.6-net-fix-user-oops-able-bug-in-fib-netlink.patch
> diff-ms-slab-numa-bind-20070514
> diff-ms-futex-locking-bug-20070510
> diff-ms-futex-oops-20070510
> diff-ms-nfs-rm-warn-20070515
> diff-ms-sparc64-compilation-20070523
> diff-ms-powerpc-compilation-20070523
> diff-ms-nfs-odirect-20070529
> diff-ms-nfs-umount-refcnt-leak-20070530
> diff-ms-nfs-schedlock-20070530
> diff-ms-nfs-launder-20070530
> diff-ms-seqfile-seek-20070601
> diff-ms-ia64-nat-ptrace-20070604
> diff-ms-net-ipv6-privacy-msg-20070605
> diff-ms-entropy-fix-a-20070530         # CVE-2007-2453
> diff-ms-entropy-fix-b-20070530         # CVE-2007-2453
> diff-ms-security-cpuset-20070605       # CVE-2007-2875
> diff-ms-security-sctp-20070604         # CVE-2007-2876
>>
> diff-ms-fuse-nlookup-20070521
> diff-ms-fuse-spurious-bug-20070521
> diff-ms-fuse-dentry-parent-20070521
> diff-ms-fuse-oops-in-lookup-20070521
> diff-ms-fuse-bug-control-fs-20070521
> diff-ms-fuse-validate-rootmode-20070521
> diff-ms-fuse-mknod-of-regular-file-20070521
>
> # diff-ms-fatal-signal-20070413
108c162
< diff-bug-macro-tune-20060310          # Send to LKML
---
> diff-bug-macro-tune-20060310-2                # Send to LKML
134a189
> diff-sysrq-debug-b-20070511
159a215
> diff-rh-mmap-return-addr-b-20070608
170a227
> diff-ms-vfs-get-host-20070515
174c231,232
< diff-ms-nmi-wdog-timeout-20070328
---
> # diff-ms-nmi-wdog-timeout-20070328
> # `- linux-2.6-nmi-change-watchdog-timeout-to-30-seconds.patch
178,179c236,237
< diff-ms-net-bridge-via-eth-20070311
< diff-rh-utrace-update-20070320
---
> # diff-rh-utrace-update-20070320
> # `- linux-2.6-utrace-exploit-and-unkillable-cpu-fixes.patch
180a239,240
> diff-rh-dlm-misc-device-fix-20070412
> diff-ms-bridge-nf-ebt-among-20070607
189d248
< # diff-ve-sysctl-allow-kthreads-20061018
224c283
< diff-ubc-kmem-20060830-3
---
> diff-ubc-kmem-20060830-4
349a409,425
> diff-ubc-refcount-leak-dupmm-20070409
> diff-ubc-vmguar-enough-null-mm-20070406
> diff-ubc-page-uncharge-bug-first-20070406
> diff-ubc-percpu-sign-expansion-20070410
> diff-ubc-dcache-uncharge-root-20070413
> diff-ubc-put-beancounters-in-fork-20070416
> diff-ubc-io-release-debug-20070416
> diff-ubc-unusedprivvm-in-zeromap-20070424
> diff-ubc-off-20070424
> diff-ubc-dentry-acentry-20070510
> diff-ubc-dentry-free_block-20070510
> diff-ubc-dentry-free_alien-20070510
> diff-ubc-dentry-free_alien-b-20070521
> diff-ubc-cleanup-20070517

> diff-ubc-proc-rework-b-20070515
> diff-ubc-proc-rework-c-20070604
> diff-ubc-unix-exports-20070604
379a456,464
> diff-ubc-ioprio-clean-active-ub-20070411
> diff-ubc-ioprio-oops-on-virt-off-20070423
> diff-ubc-ioprio-force-disp-off-20070424
> diff-ubc-ioprio-range-prio-20070623
> diff-ubc-ioprio-slice-scaling-20070623
> diff-ubc-ioprio-on-dispatch-check-20070523
>
> diff-ubc-ioacct-context-handle-20070413
> diff-ubc-top-beancounter-20070515
427a513
> diff-ve-meminfo-b-20070330
506a593
> diff-ve-futex-vpid-fix-20070413
520c607
< diff-ve-sysctl-allow-kthreads-20061018
---
> diff-ve-sysctl-allow-kthreads-20061018-2
573a661
> diff-ve-tun-persist-20070424
602a691,708
> diff-ve-kconfig-security-deps-20070411
> diff-ve-netlink-veprintk-20070426
> diff-ve-xen-netback-20070426
> diff-ve-pid-nr-fix-20070503
> diff-ve-showmem-locking-20070414
> diff-ve-init-signals-20070514
> diff-ve-proc-hash-pid-dentries-20070516
> diff-ve-cap-bset-20070504
> diff-ve-net-arp-set-perms-20070625
> diff-ve-cpustats-20070528
> diff-ve-setattr-proc-20070524
> diff-ve-setattr-proc-kmsg-20070524
> diff-ve-setattr-proc-b-20070604
> diff-ve-syslog-20070601
> diff-ve-reparent-threaded-init-20070604
> diff-ve-vpsdumpable-early-20070604
> diff-ve-oom-adjust-20070604
> diff-ve-prepare-ve0-tasks-20070608
626a733,736
> diff-ve-venet-stoprace-20070412
> diff-ve-net-veth-addr-macro-20070514
> diff-ve-net-veth-multicast-20070604
> diff-ve-net-veth-filtering-b-20070605
640a751,756
> diff-ve-nfs-hostcache-20070510
> diff-ve-nfs-stop-20070502
> diff-ve-nfs-stop-b-20070502
> diff-ve-nfs-abortset-20070504
> diff-ve-nfs-tcpabort-20070522
> diff-ve-nfs-abortcorrupt-20070523
665a782,784
> diff-ve-nf-ipt6-aliasing-20070515
> diff-ve-ip-nat-aliasing-20070605
> diff-ve-ip-nat-aliasing-b-20070607
680a800,804
> # bridges over ETH
> diff-ms-net-bridge-via-eth-20070311
> diff-ve-net-bridge-via-phys-dev2-20070514
> diff-ms-net-bridge-via-eth-c-20070613
>
717a842,849
> diff-vzdq-sleep-under-inode-lock-20070412
> diff-vzdq-ugbad-20070428
> diff-vzdq-ppc32-comp-20070518
> diff-vzdq-putsuper-20070518
> diff-vzdq-aquota-group-len-20070521
> diff-vzdq-atomic-in-buildmntlist-20070521
> diff-vzdq-for-gfs-20070521
> diff-vzdq-restore-symlinks-under-sem-20070524
723c855
< diff-cpt-exports-4
---
> diff-cpt-exports-5
770a903
> diff-cpt-inotify-core-b-20070529
842a976
> diff-cpt-kill-external-processes-b-20070515
852a987
> diff-cpt-ubc-adjust-on-restore-c-20070601
863a999,1000
> diff-cpt-4gbsplit-ldt-20070410
> diff-cpt-off-lockdep-on-sockets-20070413
868a1006,1035
> diff-cpt-make-zombie-20070413
> diff-cpt-make-zombie-b-20070420
> diff-cpt-zombie-threads-20070416
> diff-cpt-robust-list-20070413
> diff-cpt-active-callback-eagain-20070423
> diff-cpt-restore-netlink-socket-20070419
> diff-cpt-suspend-cleanup-20070510
> diff-cpt-prevent-vm-changes-20070510
> diff-cpt-features-known-mask-20070514
> diff-cpt-futex-eintr-20070510
> diff-cpt-cap-bset-20070504
> diff-cpt-xen-ldt-20070523
> diff-cpt-wait-fix-20070518
> diff-cpt-wait-fix-b-20070518
> diff-cpt-wait-fix-c-20070601
> diff-cpt-mm-deadlock-20070523
> diff-cpt-restore-lastpid-20070604
> diff-cpt-pids-leak-20070525
> diff-cpt-rst-file-error-msg-20070601
> diff-cpt-namespace-deadlock-20070604
> diff-cpt-ia64-nat-20070604
> diff-cpt-improve-align-20070604
> diff-cpt-compilation-warning-20070604
> diff-cpt-ia64-unaligned-suppress-20070604
> diff-cpt-check-iptables-modules-20070604
> diff-cpt-restore-deleted-files-20070502
> diff-cpt-deleted-ref-20070502
> diff-cpt-deleted-ref-b-20070613
> diff-cpt-restore-packet-socket-20070606
>
870a1038,1040
> # Required for VZ only:
> diff-cpt-aux-task-list-20070604
>
890a1061
> diff-fairsched-ppc-syscalls-fix3-20070525
910c1081
< diff-fairsched-get-normal-vemask-20061220
---
> diff-fairsched-get-normal-vemask-20061220-2
922a1094
> diff-fairsched-find-idle-vcpu-20070403
925a1098,1099
> diff-fairsched-best-vcpu-20070413
> diff-fairsched-best-vcpu-b-20070423
928a1103,1111
> diff-fairsched-unused-rq-20070424
> diff-fairsched-dyn-vcpu-timeslice-20070518
> diff-fairsched-vcpuoff-comp-20070426
> diff-fairsched-rename-vcpu-info-20070517
> diff-fairsched-x8664-show-regs-20070528
> diff-fairsched-boot-cpu-20070530
> diff-fairsched-preempt-20070529
> diff-fairsched-iowait-fix-20070624
> diff-fairsched-tickduration-20070528
931a1115,1122
>
> diff-ms-dcache-fix-quadratic-shrink
> diff-ubc-move-might-sleep-20070517
>
> # Xen fixes here and there...
> diff-ve-xen-blktapmain-20070514
> diff-xen-subarch-changes-20070528
> diff-ms-net-settimeout-20070525


[/code]


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14132 is a reply to message #14112] Fri, 15 June 2007 10:09 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

я так понимаю в GS загружают что-то из LDT.
В LDT есть только два вида selector'ов: default и юзер.

юзер селекторы создаются через write_ldt().
никаких подпорок в arch/i386/kernel/ldt-xen.c :: write_ldt() на эту тему я не вижу... более того, судя по всему hypervisor сам этим управляет...

default_ldt[] находится в traps-xen.c и не менялся:
struct desc_struct default_ldt[] = { { 0, 0 }, { 0, 0 }, { 0, 0 },
{ 0, 0 }, { 0, 0 } };

так что пока я в замешательстве...
какой хоть номер в этом месте у GS?


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14133 is a reply to message #14122] Fri, 15 June 2007 10:10 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

боюсь что на Ваш вопрос про оптимизацию ответить не в состоянии ;/ я в Xen вообще толком не копался еще Smile

http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14136 is a reply to message #14133] Fri, 15 June 2007 11:08 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Похоже, причина проблемы найдена. Она в том, что для openvz-варианта порушена работа VDSO. Проблемный патч openvz -- diff-cpt-vsyscall-disable. Вот его кусок:
--- ./fs/exec.c.ve254   2006-08-29 10:47:09.000000000 +0400
+++ ./fs/exec.c 2006-08-29 10:47:09.000000000 +0400
@@ -66,6 +66,8 @@ int suid_dumpable = 0;
 EXPORT_SYMBOL(suid_dumpable);
 /* The maximal length of core_pattern is also specified in sysctl.c */

+int sysctl_at_vsyscall;
+
 static struct linux_binfmt *formats;
 static DEFINE_RWLOCK(binfmt_lock);

--- ./include/asm-i386/elf.h.ve254      2006-08-29 10:47:08.000000000 +0400
+++ ./include/asm-i386/elf.h    2006-08-29 10:47:54.000000000 +0400
@@ -162,7 +162,7 @@ extern int arch_setup_additional_pages(s
 extern unsigned int vdso_enabled;

 #define ARCH_DLINFO                                            \
-do if (vdso_enabled) {                                         \
+do if (vdso_enabled && sysctl_at_vsyscall) {                   \
                NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY);            \
                NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \
 } while (0)


Можно заметить, что sysctl_at_vsyscal не инициализируется и соответственно равен 0. Поэтому ARCH_DLINFO не работает даже если vdso_enabled равно 1.

Хотелось бы узнать, что замышлялось под sysctl_at_vsyscall...

Устанавливать sysctl_at_vsyscall еще не пробовал, но то, что vdso не работает -- проверено. Конкретно билиотеки из /lib/i686/nonsegng переписаны в /lib и сообщения о 4gb seg fixup пропали. При рабочем vdso линкер сам берет библы из /lib/i686/nonsegneg

PS: теперь я понимаю, почему в Wiki openvz-xen не работала в dom0 Smile Потому что базовой системой была RHEL5. А у меня -- gentoo, собранный весь под Xen: CFLAGS="$CFLAGS -mno-tls-direct-seg-refs"
У меня -- не ругалась. А в случае Wiki должна была ругаться по-страшному и в dom0.

[Updated on: Fri, 15 June 2007 11:30]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14159 is a reply to message #14136] Sat, 16 June 2007 01:18 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

При замене проблемного кода на
#define ARCH_DLINFO                                             \
do {                                                            \
                NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY);            \
                NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \
} while (0)



проблема исчезла (решена). Ранее собирал с
#define ARCH_DLINFO                                             \
do if (vdso_enabled) {                                          \
                NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY);            \
                NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \
} while (0)

(это более правильный вариант для x86-32), но почему-то этот вариант не сработал. Возможно -- виноват какой-то глюк и сейчас повторно собираю с этим вариантом

PS: да, и второй вариант правильно работает (вероятно в первый раз промахнулся и собрал что-то другое).

[Updated on: Sat, 16 June 2007 07:33]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14169 is a reply to message #14159] Sat, 16 June 2007 17:59 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

ok. будем думать. надо еще разобраться в очередной раз с CPT vs. vsyscall на i386...


http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14191 is a reply to message #14169] Mon, 18 June 2007 13:52 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Этому 4g seg fix конца нет.... Собрал ядро с правильным include/asm/elf.h Нормально, без ругани запустил с этим ядром в domU centos5a. Читая Wiki, делаю в domU VE 134 на основе fedora-core-5-i386-minimal и запускаю. Так на тебе, опять ругань про 4g seg fix Sad

Каким образом в domU VE перестает действовать ARCH_DLINFO ? Может вообще убрать vdso_enabled? А то получается, что в VE этот vdso_enabled равен 0

PS: в dom0 этот самый 134 VE -- не ругается. А в domU -- ругается.
Пересборка ядра (выкинул вообще if vdso_enabled) не помогла -- все равно ругается в domu-ve. Замена glibc в 134 domu-ve, конечно, помогает (пишем из /lib/i686/nonsegneg в /lib).

Но запустить сеть в domu-ve мне не удалось. То есть виртуальный venet сконфигурирован, сам себя пингует, а domu -- не видит. Возможно из-за того, что в centos что-то мешает этому. Я не спец по centos. Но iptables я останавливал. Возможно, в domU надо настроить sysctl (забыл про это).

PPS: возможно что-то сглючило, но rhel5-openvz-028.035 (без xen) не загрузился. До этого я собирал 028.034 и вроде все грузилось... Ой, мамочка, точно не грузится (во второй раз пересобрал полностью). Зависает (что-то там внутри себя наверно делает) после вывода сообщения "Loading initramfs...."

Неужели из-за
diff --git a/kernel/ve/vecalls.c b/kernel/ve/vecalls.c
index d1b55a8..5ade018 100644
--- a/kernel/ve/vecalls.c
+++ b/kernel/ve/vecalls.c
@@ -1193,7 +1193,7 @@ static int do_ve_iptables(struct ve_struct *ve, __u64 init_mask,
        init_mask &= ~VE_IP_IPTABLES6;
        init_mask &= ~VE_IP_FILTER6;
        init_mask &= ~VE_IP_MANGLE6;
-       init_mask &= ~VE_IP_IPTABLE_NAT;
+       init_mask &= ~VE_IP_IPTABLE_NAT_MOD;
        if ((init_mask & VE_IP_IPTABLES) == VE_IP_IPTABLES)
                init_mask |= VE_IP_IPTABLES6;
        if ((init_mask & VE_IP_FILTER) == VE_IP_FILTER)


Проверил, не грузится 028.034 тоже. Очень вероятно, что из-за vm86.patch (теперь он подходит для xen, а без Xen не работает).
Буду пока собирать rhel5-openvz (без Xen) без этого патча.

[Updated on: Tue, 19 June 2007 06:00]

Report message to a moderator

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14250 is a reply to message #14136] Wed, 20 June 2007 13:39 Go to previous messageGo to next message
Andrey Mirkin is currently offline  Andrey Mirkin
Messages: 193
Registered: May 2006
Senior Member
sysctl_at_vsyscall ввели еще в 2.6.8.1 ядре для отключения vsyscall страницы. Потом в мейнстримном ядре была добавлена своя переменная для этого vdso_enabled, а этот патч забыли выкинуть. Так он и тянется до сих пор. Надо будет его откатить, т.к. сейчас он уже не нужен.

Andrey Mirkin
http://static.openvz.org/userbars/openvz-developer.png
Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14252 is a reply to message #14250] Wed, 20 June 2007 13:49 Go to previous message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Если откатите, то будут проблемы (у меня зависало на этапе запуска initramfs).

То есть при включенном vdso_enable на обычном rhel5-openvz-ядре (028.034 и выше, не Xen, ниже не проверял) возможны проблемы. Самое интересное, что при сборке для Xen проблем нет и все почти работает. Не работает vdso только в VE под domU. В самом domU и в VE под dom0 -- работает. Про работу vdso в dom0 ничего сказать не могу, так как еще не пробовал эти ядра запускать на RHEL5-дистре (пока для dom0 использую Gentoo)

PS: в принципе, не так уж сложно ручками заменить либы в /lib на нужные (для исключения проблем при неработающем vdso)

[Updated on: Wed, 20 June 2007 13:55]

Report message to a moderator

Previous Topic: *SOLVED* завис - проблема ovz ядра?
Next Topic: openvz и vdso -- так в чем проблема?
Goto Forum:
  


Current Time: Thu Feb 02 18:45:34 GMT 2023

Total time taken to generate the page: 0.00834 seconds