Re: [Xen-devel] Hunting down an oops in Xen 3.1.0's 2.6.18 kernel

["Michael Marineau" <mike@xxxxxxxxxxxx>]

On 9/17/07, Michael Marineau <mike@xxxxxxxxxxxx> wrote:
> On 9/15/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> > On 14/9/07 23:51, "Michael Marineau" <mike@xxxxxxxxxxxx> wrote:
> >
> > > I have been unable to reproduce this with 3.0.4's 2.6.16 kernel but
> > > 2.6.18 will oops on both 3.0.4 and 3.1.0. Also, x86_64 appears to be
> > > ok.
> > >
> > > I'm guessing this issue is the same as the oops reported here:
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=975
> > >
> > > Below is an example of the oops on my 2.6.18 pae kernel with a couple
> > > extra debuging lines added:
> >
> > Looks like xen_l1_entry_update() is passed a virtual address which has no
> > corresponding machine address. So the pte page or its mapping is corrupted
> > somehow. deadbeef in the register dumps is also not a good sign. I'll have a
> > go at repro'ing.
> >
> >  -- Keir
> >
> >
> >
>
> As for the deadbeef, I'm kind of doubt it is important. Those values
> show up after the hypercall to xen. Using the attached patch which
> checks for the bogus value prior to the call I get the following oops:
>
> virtptr: f57b40c0 machineptr: 7fffffff0c0
> ------------[ cut here ]------------
> kernel BUG at arch/i386/mm/hypervisor.c:64!
> invalid opcode: 0000 [#1]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0061:[<c0117893>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.18-xen-r5-try2 #10)
> EIP is at xen_l1_entry_update+0xd7/0x100
> eax: 0000002d   ebx: 00000000   ecx: 00000000   edx: 00000001
> esi: fffff0c0   edi: 000007ff   ebp: ed45cd10   esp: ed45ccd8
> ds: 007b   es: 007b   ss: 0069
> Process bash (pid: 5044, ti=ed45c000 task=ec835a70 task.ti=ed45c000)
> Stack: c037b964 f57b40c0 fffff0c0 000007ff 00000000 00000000 f57b40c0 fffff0c0
>        000007ff 00000000 00000000 00000000 00000000 00000000 ed45cd84 c01586b7
>        35371025 00000000 ecd95ec0 ecd95f08 c04bce70 00000000 00000004 00000000
> Call Trace:
>  [<c01586b7>] zap_pte_range+0x265/0x658
>  [<c0158c16>] unmap_page_range+0x16c/0x2b4
>  [<c0158e2c>] unmap_vmas+0xce/0x1cb
>  [<c015f0b8>] exit_mmap+0x7d/0xf4
>  [<c011e0f3>] mmput+0x36/0x8c
>  [<c01782d3>] exec_mmap+0x156/0x229
>  [<c0178a78>] flush_old_exec+0x59/0x25a
>  [<c0198a18>] load_elf_binary+0x33c/0xc52
>  [<c0178f2a>] search_binary_handler+0x89/0x23c
>  [<c017922f>] do_execve+0x152/0x1be
>  [<c010391c>] sys_execve+0x32/0x84
>  [<c0104dfb>] syscall_call+0x7/0xb
>  [<b7efd899>] 0xb7efd899
> Code: b4 97 fe ff 85 c0 78 42 83 c4 2c 5b 5e 5f 5d c3 8b 45 e0 89 74
> 24 08 89 7c 24 0
> EIP: [<c0117893>] xen_l1_entry_update+0xd7/0x100 SS:ESP 0069:ed45ccd8

I can still reproduce this problem on the 3.1.1-rc2 xen kernel. Has
anyone had a chance to take a look at this or try to reproduce it? I
can reproduce this far to easily :-(

Is there any further debugging information I can provide?

-- 
Michael Marineau
Oregon State University
mike@xxxxxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel