OpenVZ Forum - RDF feed
type: channel
items: Как там дела с 2.6.18-8.el5 028stab034.1 ?
items: Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?

Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Мож для особо нетерпеливых доступен CVS разработчиков ? А то тут занимаюсь устаревшим el5-028.027. Ситуация такая. Как dom0 ядро -- претензий нет. Запускаются и domU, и VE. А вот если пытаюсь его использовать в rPath вместо родного domU-ядра, то 1) заметно медленнее грузится 2) не выскакивает логин. То есть загрузка сервисов прошла и все. Хотя удаленно можно подключиться по ssh. Поэтому создавать внутри domU VE я еще не пробовал. Хочется понять -- где проблема. И интересно узнать о прогрессе el5-028.034 относительно Xen.
creator: seyko2
date: 2007-06-07T03:47:17-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: текущий snapshot 034 патча может быть скачан отсюда: http://download.openvz.org/~dev/patch-028stab034-core этот патч на ядро EL5-8.1.4. не тестировался мной еще вообще (иммейте это ввиду). сейчас я собираю 034 ядро и отдаю на тестинг. С CVS вопрос пока не решен, т.к. помимо чисто технических деталей - есть и полу-политические, например, как быть с security fix'ами у которых есть embargo date?
creator: dev
date: 2007-06-07T10:52:39-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Ядро собралось, но запускаться отказывается. Как 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 Этого я не понимаю... Собрать что ль чистое EL…
creator: seyko2
date: 2007-06-07T23:36:30-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Собрал чистое ядро 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.
creator: seyko2
date: 2007-06-08T04:17:59-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Создать свой domU из Virt-Manager на этот раз получилось. В предыдущие разы я пытался указать URL из интернет. На этот раз я сделал доступным у себя по FTP содержимое установочного диска CentOS5 и немного уменьшил размер максимальной памяти для domU (212МБ, всего у меня 512). 256Мб для domU не удается выделить, так как существует ограничение на минимальную память для dom0 (248?), плюс около 48Мб отъедает сам Xen-монитор. PS: при указании завышенного RAM для domU (которое нельзя выделить), выдается сообщение о невозможности создать виртуальную машину
creator: seyko2
date: 2007-06-08T06:14:28-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: сейчас чиним...
creator: dev
date: 2007-06-08T07:45:17-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: первая часть фиксится убиранием всех init_v0_process() из init_ve_system(). теперь проблема с самими VE. Я вам выдам полный патчик через какое-то время когда буду готов ставить ядро на билд.
creator: dev
date: 2007-06-08T08:05:57-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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); }
creator: dev
date: 2007-06-08T08:25:05-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: fixed patch-028stab034-core uploaded to the same URL
creator: dev
date: 2007-06-08T08:32:09-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: С исправленным патчем domU-ядро работает. А вот dom0-ядро лично у меня перегружается на попытке определить тип монитора через DDC ddcxinfo-knoppix -monitor Сейчас выкину это из загрузочных скриптов и попробую снова загрузиться
creator: seyko2
date: 2007-06-09T04:11:54-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: ok. чуть-чуть продвинулись. Не помню, мне Женя что-то говорил что у него и родной RHEL5 в Dom0 не работает...
creator: dev
date: 2007-06-09T07:40:38-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Нет, родной работает. И полученный 028.034 dom0 работает. Только падает на ddcxinfo-knoppix. Без ddcxinfo-knoppix вроде все нормально. 028.027 -- не падает. С добавленными патчами openvz до 028.033 -- не падает. Похоже проблема с добавленными патчами, специфичными для rhel5. Может что-то для работы с большой памятью или обработкой bios-вызовов (ddcxinfo - он пытается пользовать vesa-вызова, как я понимаю) Как бы узнать список патчей от команды openvz, которые специфичны для ядра rhel5 (отсутствуют в чистом openvz)
creator: seyko2
date: 2007-06-10T05:31:30-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Найдите два отличия... Вот возникли вопросы по поводу обсуждаемого 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 это не …
creator: seyko2
date: 2007-06-10T20:33:07-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: разница между 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
creator: seyko2
date: 2007-06-11T04:12:31-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Просьба: проанализировать изменения в файле arch/i386/kernel/vm86.c на предмет правильности работы в dom0. Ибо откат этих изменений позволил нормально отработать программе ddcxinfo-knoppix -monitor Ну и учесть рекомендуемый патч плюс замечание по net/sunrpc/clnt.c (отсутствует if (!IS_ERR(new->cl_dentry)))
creator: seyko2
date: 2007-06-11T05:09:32-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: С вот таким патчем для 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;
creator: seyko2
date: 2007-06-12T03:37:04-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Только что-то я не понимаю... Грузим в 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 для
creator: seyko2
date: 2007-06-12T14:55:52-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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 - он вряд ли умеет обрабатывать). меньше изменений - легче жить.
creator: dev
date: 2007-06-13T07:46:33-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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 не нужны. Огромное спасибо!
creator: dev
date: 2007-06-13T08:30:24-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект. давай-те его чинить Quote: Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для нет, vm86.c менялся не из-за ругани, а в соответствие с 4gb split'ом. Когда эта фича включена, то TSS, GDT, LDT и прочее начинает управляться иным образом, поэтому и патч такой гигантский.
creator: dev
date: 2007-06-13T08:35:04-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: cl_dentry проверяется позже, так что проблемы нет.
creator: dev
date: 2007-06-13T08:44:24-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Осталось только пропатчить 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 Собрал сам на всякий случай я…
creator: seyko2
date: 2007-06-13T20:28:22-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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 +++…
creator: dev
date: 2007-06-14T11:25:13-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: За патчи спасибо! Про ругань: запускаем только 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 и без) и все как-то неудачно -- ядро часто через некоторое время начинало тормозить и глюкавить.
creator: seyko2
date: 2007-06-14T14:29:58-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: вероятно опять-таки виноват 4GB split, но я пока не понимаю как... :/
creator: dev
date: 2007-06-14T14:34:40-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Кстати, буду премного благодерн если Вы найдете время и силы как-нибудь посмотреть на эту wiki страничку: https://wiki.openvz.org/How_to_use_OpenVZ_as_a_XEN_guest_OS_ %28for_x86_platform%29 Предупреждаю сразу, она совсем не кузява :/, т.к. писал человек не очень опытный. Поэтому буду очень благодарен за помощь в ее доведении до ума.
creator: dev
date: 2007-06-14T18:42:44-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Вот как выглядят сообщения 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 Сообщени…
creator: seyko2
date: 2007-06-14T19:14:08-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: А вообще это сообщение выдается при выполнеии инструкции в пользовательской программе, которая обращается к памяти данных с использованием GS: и прерывается по защите памяти, если смещение велико и попадает в область памяти, занимаемой Xen-монитором (реальный 4Gb сегмент). Ками-то образом программы получают от openvz-ядра сегмент для данных, который не урезан с учетом Xen.
creator: seyko2
date: 2007-06-15T05:51:08-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Про 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 происходит.
creator: seyko2
date: 2007-06-15T06:53:45-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: С 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 тоже не должно.
creator: seyko2
date: 2007-06-15T07:36:01-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: 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-i…
creator: dev
date: 2007-06-15T10:02:00-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: я так понимаю в 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?
creator: dev
date: 2007-06-15T10:09:04-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: боюсь что на Ваш вопрос про оптимизацию ответить не в состоянии ;/ я в Xen вообще толком не копался еще
creator: dev
date: 2007-06-15T10:10:29-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Похоже, причина проблемы найдена. Она в том, что для 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 Потому что базовой системой была RHEL5. А у меня -- gentoo, собранный весь под Xen: CFLAGS="$CFLAGS -mno-tls-direct-seg-refs" У меня -- не ругалась. А в случае Wiki должна была ругаться по-страшному и в dom0.
creator: seyko2
date: 2007-06-15T11:08:18-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: При замене проблемного кода на #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: да, и второй вариант правильно работает (вероятно в первый раз промахнулся и собрал что-то другое).
creator: seyko2
date: 2007-06-16T01:18:35-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: ok. будем думать. надо еще разобраться в очередной раз с CPT vs. vsyscall на i386...
creator: dev
date: 2007-06-16T17:59:47-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Этому 4g seg fix конца нет.... Собрал ядро с правильным include/asm/elf.h Нормально, без ругани запустил с этим ядром в domU centos5a. Читая Wiki, делаю в domU VE 134 на основе fedora-core-5-i386-minimal и запускаю. Так на тебе, опять ругань про 4g seg fix Каким образом в 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) без этого патча.
creator: seyko2
date: 2007-06-18T13:52:22-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: sysctl_at_vsyscall ввели еще в 2.6.8.1 ядре для отключения vsyscall страницы. Потом в мейнстримном ядре была добавлена своя переменная для этого vdso_enabled, а этот патч забыли выкинуть. Так он и тянется до сих пор. Надо будет его откатить, т.к. сейчас он уже не нужен.
creator: Andrey Mirkin
date: 2007-06-20T13:39:02-00:00

Re: Как там дела с 2.6.18-8.el5 028stab034.1 ?
type: item
description: Если откатите, то будут проблемы (у меня зависало на этапе запуска initramfs). То есть при включенном vdso_enable на обычном rhel5-openvz-ядре (028.034 и выше, не Xen, ниже не проверял) возможны проблемы. Самое интересное, что при сборке для Xen проблем нет и все почти работает. Не работает vdso только в VE под domU. В самом domU и в VE под dom0 -- работает. Про работу vdso в dom0 ничего сказать не могу, так как еще не пробовал эти ядра запускать на RHEL5-дистре (пока для dom0 использую Gentoo) PS: в принципе, не так уж сложно ручками заменить либы в /lib на нужные (для исключения проблем при неработающем vdso)
creator: seyko2
date: 2007-06-20T13:49:03-00:00