Re: potentially nasty oops on startup

Re: potentially nasty oops on startup

[Thomas Ronner]

Hello,

 >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 
 > > 00000449

 > OK, figured it out.  It"s kmodule, mmaping /dev/mem and
 > making vm86 calls.  Select fragments from a strace:
(...)

I'm having the same problem on Xen 2.0.3 using the stock XenLinux 2.6.10 
kernel. This didn't happen with Xen 2.0.1 and XenLinux 2.6.9. Is there a 
fix available? in -testing perhaps? The distribution in domain 0 is FC3.


Greetings, Thomas

-- 
Thomas Ronner
Computer Systems Group
Institute of Information & Computing Sciences, Utrecht University
E: thomas@cs.uu.nl  T: 030 2539296



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

RE: potentially nasty oops on startup

[Ian Pratt]

> 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/

RE: potentially nasty oops on startup

[Rik van Riel]

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/

potentially nasty oops on startup

[Rik van Riel]

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/

Re: potentially nasty oops on startup

[Rik van Riel]

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 00000449

OK, 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/