Hi,
I''m getting the following oops on startup, and I''m not quite
sure why. It looks nasty though, with an invalid page being
mapped into a process, and a strange looking EIP ...
do_wp_page: bogus page at address 00000449
VM: killing process kmodule
Unable to handle kernel NULL pointer dereference at virtual address 00000449
printing eip:
00001eca
*pde = ma 0d183067 pa 0a583067
*pte = ma 00000025 pa 55555025
[<c010d91c>] syscall_call+0x7/0xb
Oops: 0003 [#1]
Modules linked in: ext3 jbd
CPU: 0
EIP: c000:[<00001eca>] Not tainted VLI
EFLAGS: 00033206 (2.6.9-1.1009_FC4xen0)
EIP is at 0x1eca
eax: 00004f03 ebx: 00000000 ecx: 00000000 edx: 00000000
esi: 00000000 edi: 00000000 ebp: 00000fdc esp: c8f99f24
ds: 0000 es: 0000 ss: 0069
Process kmodule (pid: 584, threadinfo=c8f99000 task=c8a88d30)
Stack: 00000fd0 00001000 00001101 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call Trace:
[<c010d91c>] syscall_call+0x7/0xb
Code: Bad EIP value.
<6>e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> I''m getting the following oops on startup, and I''m not quite > sure why. It looks nasty though, with an invalid page being > mapped into a process, and a strange looking EIP ...Ouch. Is this the unstable tree? Is it deterministic? How far through the boot process does it happen? Could you try rolling the tree back a couple of days and check it goes away. Almost all the core Xen developers are currently in San Francisco attending OSDI, so I''m afraid bug fix response times might not be quite as good as usual. Ian> do_wp_page: bogus page at address 00000449 > VM: killing process kmodule > Unable to handle kernel NULL pointer dereference at virtual > address 00000449 > printing eip: > 00001eca > *pde = ma 0d183067 pa 0a583067 > *pte = ma 00000025 pa 55555025 > [<c010d91c>] syscall_call+0x7/0xb > > Oops: 0003 [#1] > Modules linked in: ext3 jbd > CPU: 0 > EIP: c000:[<00001eca>] Not tainted VLI > EFLAGS: 00033206 (2.6.9-1.1009_FC4xen0) > EIP is at 0x1eca > eax: 00004f03 ebx: 00000000 ecx: 00000000 edx: 00000000 > esi: 00000000 edi: 00000000 ebp: 00000fdc esp: c8f99f24 > ds: 0000 es: 0000 ss: 0069 > Process kmodule (pid: 584, threadinfo=c8f99000 task=c8a88d30) > Stack: 00000fd0 00001000 00001101 00000000 00000000 00000000 > 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 > 80000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 Call Trace: > [<c010d91c>] syscall_call+0x7/0xb > > Code: Bad EIP value. > <6>e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide Read honest & > candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel > >------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sun, 5 Dec 2004, Ian Pratt wrote:>> I''m getting the following oops on startup, and I''m not quite >> sure why. It looks nasty though, with an invalid page being >> mapped into a process, and a strange looking EIP ... > > Ouch. Is this the unstable tree? Is it deterministic? How far through > the boot process does it happen? Could you try rolling the tree back a > couple of days and check it goes away.It is the unstable tree, I''ll try running an older kernel and Xen to see if the bug goes away.> Almost all the core Xen developers are currently in San Francisco > attending OSDI, so I''m afraid bug fix response times might not be quite > as good as usual.Cool. I hope you''re having a great time at OSDI. Don''t worry about fixing this bug in a hurry, there''s enough time later... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sun, 5 Dec 2004, Rik van Riel wrote:> I''m getting the following oops on startup, and I''m not quite > sure why. It looks nasty though, with an invalid page being > mapped into a process, and a strange looking EIP ... > > do_wp_page: bogus page at address 00000449 > VM: killing process kmodule > Unable to handle kernel NULL pointer dereference at virtual address 00000449OK, figured it out. It''s kmodule, mmaping /dev/mem and making vm86 calls. Select fragments from a strace: geteuid32() = 0 open("/dev/zero", O_RDONLY) = 4 mmap2(0x10000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x10000 open("/dev/mem", O_RDWR) = 5 mmap2(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0 mmap2(0xa0000, 393216, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 5, 0xa0) = 0xa0000 iopl(0x3) = 0 ioperm(0, 0x400, 0x1) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 vm86old(0x806b48c <unfinished ...> +++ killed by SIGSEGV +++ Can''t say I blame Xen for this. Yuck. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel