[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] pv_ops domU crashes on pv_ops dom0 (directly at boot)



On Tue, Jan 19, 2010 at 01:10:27PM +0100, Markus Schuster wrote:
> On Tuesday 19 January 2010 12:46:37 Pasi Kärkkäinen wrote:
> > On Tue, Jan 19, 2010 at 12:38:47PM +0100, Markus Schuster wrote:
> > > On Tuesday 19 January 2010 12:17:33 Pasi Kärkkäinen wrote:
> > > > What's the hypervisor version btw?
> > >
> > > That's 3.4.2 (from Debian sid)
> > >
> > > > When the guest is crashed, run in dom0:
> > > >
> > > > /usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domid>
> > >
> > > Here we go:
> > > rip: ffffffff8100930a _stext+0x30a
> > > flags: 00001246 i z p
> > > rsp: ffff880002c33e60
> > > rax: 0000000000000000   rcx: ffffffff8100930a   rdx: 0000000000000000
> > > rbx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000002
> > > rbp: ffff880002c5d1d0    r8: ffff880002c3c590    r9: ffff880002c33e90
> > > r10: 00025c9e9c681d15   r11: 0000000000000246   r12: ffff880002c33e88
> > > r13: 0000000000000004   r14: 0000000000000000   r15: 0000000000000000
> > >  cs: e033        ss: e02b        ds: 0000        es: 0000
> > >  fs: 0000 @ 0000000000000000
> > >  gs: 0000 @ ffff880002c30000/0000000000000000
> > > Code (instr addr ffffffff8100930a)
> > > cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 18 00 00 00 0f 05 <41> 5b 59
> > > c3 cc cc cc cc cc cc cc
> > >
> > >
> > > Stack:
> > >  ffffffff811e49da 0000000000000080 ffffffff8100e656 0000000000000001
> > >  ffffffff8107498b ffff880002c33e88 ffff880002c33e88 ffffffff8142d740
> > >  ffff880017c14180 0000000000000004 ffffffff8100e834 0000000067559fe6
> > >  ffffffff810937c8 ffff880002c45f00 ffffffff8142d740 ffffffff8142d7ac
> > >
> > > Call Trace:
> > >   [<ffffffff8100930a>] _stext+0x30a  <--
> > >   [<ffffffff811e49da>] set_affinity_irq+0x5a
> > >   [<ffffffff8100e656>] stop_self+0x2e
> > >   [<ffffffff8107498b>] generic_smp_call_function_single_interrupt+0xc0
> > >   [<ffffffff8100e834>] xen_call_function_single_interrupt+0xe
> > >   [<ffffffff810937c8>] handle_IRQ_event+0x58
> > >   [<ffffffff81095150>] handle_level_irq+0x6a
> > >   [<ffffffff81013917>] handle_irq+0x17
> > >   [<ffffffff811e454c>] xen_evtchn_do_upcall+0x102
> > >   [<ffffffff81011cbe>] xen_do_hypervisor_callback+0x1e
> > 
> > Ok, thanks. Also please do:
> > 
> > gdb vmlinux
> > 
> > x/i 0xffffffff8100930a
> > list *0xffffffff8100930a
> > disas 0xffffffff8100930a
> > 
> > Those should be useful to debug this.
> 
> OK, that's not so easy as I'm using binary kernel packages from Debian so I 
> only have vmlinuz images laying around (and gdb is not happy about them). 
> I have to recompile Debians kernel to have a vmlinux file (not a big problem 
> - 
> costs a bit of time, that's all).
> Should I activate CONFIG_DEBUG_INFO btw?
> 
> You may remember, Jeremy was interested in similar information (but he 
> extracted the memory address (??) to pass to gdb from the kernels crash dump) 
> - I will forward you my old e-mail off-list, maybe it's interesting :) 
> 

The memory address in that earlier try was different, and the function name 
looked
different aswell..

And yeah, I guess CONFIG_DEBUG_INFO doesn't hurt :)

so it would be good to check/verify those again for this exact kernel. 
After you've rebuilt the kernel, run xenctx again to verify the rip/eip
address and run the gdb commands for that address.

-- Pasi


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.