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  |
|
|
Мож для особо нетерпеливых доступен 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 #13920 is a reply to message #13902] |
Thu, 07 June 2007 23:36  |
|
|
Ядро собралось, но запускаться отказывается. Как 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 |
|
|
Собрал чистое ядро 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 |
|
|
Создать свой 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 #13938 is a reply to message #13934] |
Fri, 08 June 2007 08:25 |
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);
}
|
|
|
|
|
|
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14009 is a reply to message #13995] |
Sun, 10 June 2007 05:31 |
|
|
Нет, родной работает. И полученный 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 |
|
|
Найдите два отличия... Вот возникли вопросы по поводу обсуждаемого 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 |
|
|
разница между 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 #14027 is a reply to message #14015] |
Tue, 12 June 2007 03:37 |
|
|
С вот таким патчем для 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, ¤t->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 |
|
|
Только что-то я не понимаю... Грузим в 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 |
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 - он вряд ли умеет обрабатывать). меньше изменений - легче жить.
[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 |
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 не нужны.
Огромное спасибо!
[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 |
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. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект.
|
давай-те его чинить 
| Quote: |
Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для
|
нет, vm86.c менялся не из-за ругани, а в соответствие с 4gb split'ом. Когда эта фича включена, то TSS, GDT, LDT и прочее начинает управляться иным образом, поэтому и патч такой гигантский.
|
|
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14063 is a reply to message #14042] |
Wed, 13 June 2007 20:28 |
|
|
Осталось только пропатчить 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 |
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 как раз это и происходит. На хосте по идее все должно быть пучком.
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14091 is a reply to message #14086] |
Thu, 14 June 2007 14:29 |
|
|
За патчи спасибо!
Про ругань: запускаем только 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 #14107 is a reply to message #14092] |
Thu, 14 June 2007 19:14 |
|
|
Вот как выглядят сообщения
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 |
|
|
|
А вообще это сообщение выдается при выполнеии инструкции в пользовательской программе, которая обращается к памяти данных с использованием 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 |
|
|
Про 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 |
|
|
С 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 |
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]
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14132 is a reply to message #14112] |
Fri, 15 June 2007 10:09 |
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?
|
|
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14136 is a reply to message #14133] |
Fri, 15 June 2007 11:08 |
|
|
Похоже, причина проблемы найдена. Она в том, что для 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.
[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 |
|
|
При замене проблемного кода на
#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 #14191 is a reply to message #14169] |
Mon, 18 June 2007 13:52 |
|
|
Этому 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) без этого патча.
[Updated on: Tue, 19 June 2007 06:00] Report message to a moderator |
|
|
|
|
|
| Re: Как там дела с 2.6.18-8.el5 028stab034.1 ? [message #14252 is a reply to message #14250] |
Wed, 20 June 2007 13:49 |
|
|
Если откатите, то будут проблемы (у меня зависало на этапе запуска 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 |
|
|
|
Goto Forum:
Current Time: Sat Dec 21 14:33:02 GMT 2024
Total time taken to generate the page: 0.04727 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
