From: antoine <an...@na...> - 2005-07-22 11:35:57
|
Paolo, I've just stared testing your latest patches on a amd64 box running 2.6.13-rc3-git4, bb8 seems to run (so far) but bs7 comes up with: ./vmlinux mem=128M root=/dev/ubda ubd0=./root_fs (...) [42949373.440000] Initializing software serial port version 1 [42949373.440000] ubda: unknown partition table [42949373.810000] kjournald starting. Commit interval 5 seconds [42949373.810000] EXT3-fs: mounted filesystem with ordered data mode. [42949373.810000] VFS: Mounted root (ext3 filesystem) readonly. [42949374.110000] Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x0 [42949374.110000] [42949374.110000] Modules linked in: [42949374.110000] Pid: 1, comm: init Not tainted 2.6.12-bs7 [42949374.110000] RIP: 4000:[<0000000000000000>] [42949374.110000] RSP: 00000000604a7c30 EFLAGS: 00010202 [42949374.110000] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000601a14ea [42949374.110000] RDX: 00000000600108de RSI: 0000000000000001 RDI: 00000000604a7b00 [42949374.110000] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffffffff [42949374.110000] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000 [42949374.110000] R13: 0000000000000000 R14: 000000000000000a R15: 0000000000000009 [42949374.110000] Call Trace: [42949374.110000] 604a7708: [<600163cf>] panic_exit+0x2f/0x50 [42949374.110000] 604a7728: [<6004f6eb>] notifier_call_chain+0x2b/0x50 [42949374.110000] 604a7758: [<6003d104>] panic+0xe4/0x180 [42949374.110000] 604a7798: [<601a14ea>] sigprocmask+0x4a/0xb0 [42949374.110000] 604a77d8: [<6001529f>] handle_page_fault+0x9f/0x2b0 [42949374.110000] 604a7848: [<60015663>] segv+0x1b3/0x270 [42949374.110000] 604a78d8: [<60012fc1>] change_signals+0x51/0x80 [42949374.110000] 604a7928: [<60015af9>] segv_handler+0x169/0x1f0 [42949374.110000] 604a7978: [<6001928a>] sig_handler_common_tt +0xfa/0x1a0 [42949374.110000] 604a79e8: [<601a1270>] __restore_rt+0x0/0x10 [42949374.110000] 604a7a78: [<600108de>] run_kernel_thread+0x2e/0x50 [42949374.110000] 604a7a88: [<601a14ea>] sigprocmask+0x4a/0xb0 [42949374.110000] 604a7ae8: [<600108f1>] run_kernel_thread+0x41/0x50 [42949374.110000] 604a7af8: [<6000d190>] init+0x0/0xf0 [42949374.110000] 604a7b38: [<600108de>] run_kernel_thread+0x2e/0x50 [42949374.110000] 604a7be8: [<60017773>] new_thread_handler+0x113/0x130 [42949374.110000] 604a7cd8: [<601a14ea>] sigprocmask+0x4a/0xb0 [42949374.110000] [42949374.110000] I haven't got much time at the moment to help with testing but things should get back to normal in the next few days. Thanks Antoine |
From: Blaisorblade <bla...@ya...> - 2005-07-22 18:21:26
|
On Friday 22 July 2005 13:35, antoine wrote: > Paolo, > I've just stared testing your latest patches on a amd64 box running > 2.6.13-rc3-git4, bb8 seems to run (so far) Using TT or SKAS0 mode? And is this specific to that host release wrt 2.6.12? > but bs7 comes up with: > ./vmlinux mem=128M root=/dev/ubda ubd0=./root_fs > [42949373.810000] VFS: Mounted root (ext3 filesystem) readonly. > [42949374.110000] Kernel panic - not syncing: Kernel mode fault at addr > 0x0, ip 0x0 > [42949374.110000] > [42949374.110000] Modules linked in: > [42949374.110000] Pid: 1, comm: init Not tainted 2.6.12-bs7 > [42949374.110000] RIP: 4000:[<0000000000000000>] > [42949374.110000] RSP: 00000000604a7c30 EFLAGS: 00010202 > [42949374.110000] RAX: 0000000000000001 RBX: 0000000000000000 RCX: > 00000000601a14ea > [42949374.110000] RDX: 00000000600108de RSI: 0000000000000001 RDI: > 00000000604a7b00 > [42949374.110000] RBP: 0000000000000000 R08: 0000000000000000 R09: > 00000000ffffffff > [42949374.110000] R10: 0000000000000008 R11: 0000000000000246 R12: > 0000000000000000 > [42949374.110000] R13: 0000000000000000 R14: 000000000000000a R15: > 0000000000000009 > [42949374.110000] Call Trace: > [42949374.110000] 604a7708: [<600163cf>] panic_exit+0x2f/0x50 > [42949374.110000] 604a7728: [<6004f6eb>] notifier_call_chain+0x2b/0x50 > [42949374.110000] 604a7758: [<6003d104>] panic+0xe4/0x180 > [42949374.110000] 604a7798: [<601a14ea>] sigprocmask+0x4a/0xb0 > [42949374.110000] 604a77d8: [<6001529f>] handle_page_fault+0x9f/0x2b0 > [42949374.110000] 604a7848: [<60015663>] segv+0x1b3/0x270 > [42949374.110000] 604a78d8: [<60012fc1>] change_signals+0x51/0x80 > [42949374.110000] 604a7928: [<60015af9>] segv_handler+0x169/0x1f0 > [42949374.110000] 604a7978: [<6001928a>] sig_handler_common_tt > +0xfa/0x1a0 > [42949374.110000] 604a79e8: [<601a1270>] __restore_rt+0x0/0x10 > [42949374.110000] 604a7a78: [<600108de>] run_kernel_thread+0x2e/0x50 > [42949374.110000] 604a7a88: [<601a14ea>] sigprocmask+0x4a/0xb0 > [42949374.110000] 604a7ae8: [<600108f1>] run_kernel_thread+0x41/0x50 > [42949374.110000] 604a7af8: [<6000d190>] init+0x0/0xf0 > [42949374.110000] 604a7b38: [<600108de>] run_kernel_thread+0x2e/0x50 > [42949374.110000] 604a7be8: [<60017773>] new_thread_handler+0x113/0x130 > [42949374.110000] 604a7cd8: [<601a14ea>] sigprocmask+0x4a/0xb0 > I haven't got much time at the moment to help with testing but things > should get back to normal in the next few days. > Thanks > Antoine -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade |
From: antoine <an...@na...> - 2005-08-03 17:42:01
|
> > I've just stared testing your latest patches on a amd64 box running > > 2.6.13-rc3-git4, bb8 seems to run (so far) > Using TT or SKAS0 mode? And is this specific to that host release wrt 2.6.12? > > but bs7 comes up with: (...) bs works fine on 2.6.13-rc4 now, must have been a host bug? But all guest 64-bit kernels are still loosing memory fast, gentoo's "emerge --sync" is enough to eat 300+ MB of ram! (in about 5 minutes) Antoine |
From: antoine <an...@na...> - 2005-08-04 17:57:34
|
On Wed, 2005-08-03 at 18:40 +0100, antoine wrote: > > > I've just stared testing your latest patches on a amd64 box running > > > 2.6.13-rc3-git4, bb8 seems to run (so far) > > Using TT or SKAS0 mode? And is this specific to that host release wrt 2.6.12? > > > but bs7 comes up with: > (...) > bs works fine on 2.6.13-rc4 now, must have been a host bug? > But all guest 64-bit kernels are still loosing memory fast, gentoo's > "emerge --sync" is enough to eat 300+ MB of ram! (in about 5 minutes) I can get a similar behavior from 2.6.12.3-bs9 guest (compiled with SUBARCH=i386) on a 2.6.13-rc5 host! The strange thing is that the same config file, same guest source but compiled without SUBARCH (ie: regular 64-bit guest) works ok (well still loosing memory fast - but at least it runs) strace ./vmlinux-2.6.12.3-bs9-x86 gives: (...) open("/home/antoine/.uml/pX0UwE/pid", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 6 getpid() = 18680 write(6, "18680\n", 6) = 6 close(6) = 0 mprotect(0xa0256000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 write(1, "OK\n", 3) = 3 rt_sigaction(SIGPIPE, {0x1000000000000001, [], 0}, {SIG_DFL}, 8) = 0 socketcall(0x8, 0xffffcb70) = 0 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 rt_sigaction(SIGWINCH, {0x10000000a0019a60, [], 0}, {SIG_DFL}, 8) = 0 getpid() = 18680 clone(child_stack=0xa0257fd4, flags=CLONE_FILES|SIGCHLD) = 18681 waitpid(18681, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WSTOPPED) = 18681 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(0x15 /* PTRACE_??? */, 18681, 0, 0x1) = 0 ptrace(PTRACE_CONT, 18681, 0, SIG_0) = 0 rt_sigaction(SIGSEGV, {0x10000000a0019be0, [], 0}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR1, {0x10000000a00184f0, [], 0}, {SIG_DFL}, 8) = 0 waitpid(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 18681 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 18681, 0, SIGSEGV) = 0 waitpid(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 18681 --- SIGCHLD (Child exited) @ 0 (0) --- munmap(0, 2692743168) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Antoine |
From: Blaisorblade <bla...@ya...> - 2005-08-04 18:47:02
|
On Thursday 04 August 2005 20:56, antoine wrote: > On Wed, 2005-08-03 at 18:40 +0100, antoine wrote: > > > > I've just stared testing your latest patches on a amd64 box running > > > > 2.6.13-rc3-git4, bb8 seems to run (so far) > > > > > > Using TT or SKAS0 mode? And is this specific to that host release wrt > > > 2.6.12? > > > > > > > but bs7 comes up with: > > > > (...) > > bs works fine on 2.6.13-rc4 now, must have been a host bug? > > But all guest 64-bit kernels are still loosing memory fast, gentoo's > > "emerge --sync" is enough to eat 300+ MB of ram! (in about 5 minutes) > > I can get a similar behavior from 2.6.12.3-bs9 guest (compiled with > SUBARCH=i386) on a 2.6.13-rc5 host! Ehr - can you bug Jeff for these? After trying on a 2.6.12.3 host - I wouldn't call -rc5 "stable", by just looking at the changelog *after* the release. I'm going to be *offline* so unable to handle this stuff. > The strange thing is that the same config file, same guest source but > compiled without SUBARCH (ie: regular 64-bit guest) works ok (well still > loosing memory fast - but at least it runs) > > strace ./vmlinux-2.6.12.3-bs9-x86 gives: > (...) Which test is it performing when it locks up? It is printing "ok" below, so... > open("/home/antoine/.uml/pX0UwE/pid", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, > 0644) = 6 > getpid() = 18680 > write(6, "18680\n", 6) = 6 > close(6) = 0 > mprotect(0xa0256000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 //Here > write(1, "OK\n", 3) = 3 > rt_sigaction(SIGPIPE, {0x1000000000000001, [], 0}, {SIG_DFL}, 8) = 0 > socketcall(0x8, 0xffffcb70) = 0 > fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > rt_sigaction(SIGWINCH, {0x10000000a0019a60, [], 0}, {SIG_DFL}, 8) = 0 > getpid() = 18680 > clone(child_stack=0xa0257fd4, flags=CLONE_FILES|SIGCHLD) = 18681 > waitpid(18681, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WSTOPPED) = > 18681 > --- SIGCHLD (Child exited) @ 0 (0) --- > ptrace(0x15 /* PTRACE_??? */, 18681, 0, 0x1) = 0 > ptrace(PTRACE_CONT, 18681, 0, SIG_0) = 0 > rt_sigaction(SIGSEGV, {0x10000000a0019be0, [], 0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x10000000a00184f0, [], 0}, {SIG_DFL}, 8) = 0 Ok, the below is actually a 32-bit "-1" value (not verified), so it shouldn't be bogus. > waitpid(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], > WSTOPPED) = 18681 > --- SIGCHLD (Child exited) @ 0 (0) --- > ptrace(PTRACE_CONT, 18681, 0, SIGSEGV) = 0 Same here > waitpid(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], > WSTOPPED) = 18681 > --- SIGCHLD (Child exited) @ 0 (0) --- The below *is* IMHO bogus (munmap from 0 is useless). > munmap(0, 2692743168) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > Antoine -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |