Re: Xen4.2-rc3 test result

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Sep 07, 2012 at 08:01:37AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Thursday, September 06, 2012 7:12 PM
> > To: Ren, Yongjie
> > Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> > Beulich'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > 
> > On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > > Konrad Rzeszutek Wilk
> > > > Sent: Saturday, September 01, 2012 1:24 AM
> > > > To: Ren, Yongjie
> > > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > > Rzeszutek Wilk'
> > > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > >
> > > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > > when pci assignment conflicts
> > > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > > >
> > > > Um, so you are assigning the same VF to two guests. I am surprised
> > that
> > > > the tools even allowed you to do that. Was 'xm' allowing you to do
> > that?
> > > >
> > > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> > different guests.
> > > Sorry, the description of this bug is not accurate. I changed its title to
> > "Dom0 cannot be shut down before PCI device detachment from a guest".
> > > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> > shutting down.
> > 
> > And does it panic if you use the 'irqpoll' option it asks for?
> >
> Adding 'irqpoll' makes no change.
> 
> It should be a regression for Xen from 4.1 to 4.2.
> I didn't meet this issue with 4.2 Xen and 3.5.3 Dom0.

Aaah. That was not clear from the bugzilla.

> 
> > Xen-pciback has no involvment as:
> > 
> > 
> > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> > Connected, skipping
> > 
> > and the guest still keeps on getting interrupts.
> > 
> > What is the stack at the hang?
> >
> [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected,
> skipping
> [  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
> Connected, skipping
> [  283.747515] xenbus_dev_shutdown: backend/console/2/0: Initialising !=
> Connected, skipping
> [  380.236571] irq 16: nobody cared (try booting with the "irqpoll" option)
> [  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
> [  380.236596] Call Trace:
> [  380.236601]  <IRQ>  [<ffffffff8110b538>] __report_bad_irq+0x38/0xd0
> [  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
> [  380.236637]  [<ffffffff81108ffa>] handle_irq_event_percpu+0xca/0x230
> [  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
> [  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
> [  380.236671]  [<ffffffff8131c8f1>] __xen_evtchn_do_upcall+0x1b1/0x280
> [  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
> [  380.236716]  [<ffffffff816bc36e>] xen_do_hypervisor_callback+0x1e/0x30
> [  380.236723]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
> [  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
> [  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
> [  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
> [  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
> [  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
> [  380.236821]  [<ffffffff81ca9346>] ? x86_64_start_reservations+0x131/0x136
> [  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
> [  380.236841] handlers:
> [  380.236850] [<ffffffff81428d80>] usb_hcd_irq
> [  380.236860] Disabling IRQ #16

That is not the hang stack. That is the kernel telling you that something
has gone astray with an interrupt. But its unclear what happend _after_ that.

It might be that the system called the proper shutdown hypercall and its
waiting for the hypervisor to do its stuff. Can you try using the 'q' to get
a stack dump of the dom0 and see where its spinning/sitting please?
>