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

[Xen-devel] IRQs, move_in_progress, -EBUSY &c


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Wed, 11 Aug 2010 15:56:08 +0100
  • Cc:
  • Delivery-date: Wed, 11 Aug 2010 07:57:21 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=hk+kRODpLcYCuC8nQLG/IpJ+ng+Sc4JcPioicczoJnfWCMc8zZH/fse9gxKQuOvFRk KSKnCvRoouZJ7i2Gf//Eue2SGVmm37Uy735+n41kzAo28oWpvpy1prfeTNpvKhHekqBG uMd4CbmLlGNZcyJ0IncOp0GdTmJtvvOHoGz5M=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I have a machine on which the pvops kernel boots fine in bare metal,
but when running under Xen, times out waiting for the root device.
The console log (with some additional messages added to track back the
root problem) is attached.

Going backwards to the root of the problem: The root device times out
even though the device driver successfully loads and sees the device
-- it complains about missing interrupts.  It misses interrupts
because the PHYSDEVOP_setup_gsi returns -16, EBUSY, and the pvops
kernel doesn't retry; so the gsi is never set up.

PHYSDEVOP_setup_gsi returns -EBUSY because the IRQ in question is
marked move_in_progress.  It was marked move_in_progress earlier when
one of the serial drivers remapped the first 15 IRQs.  (At least, I
presume it's the serial driver, since it happens immediately after the
serial driver is loaded; I could be wrong.)

I have a simple work-around, which is to set dom0_max_vcpus=0 on the
Xen command line; the guest successfully boots after that.  (So I
should be able to test those p2m patches that have been queued up for
a few weeks now.)

However, it seems that moving IRQs is not handled properly.  Either
the pvops kernel should retry if it gets an -EBUSY, or the hypercall
should not fail, but wait until it can return success.

I discovered all this by adding debug statements to the IRQ path; the
patch is attached, if anyone else wants to use it.

 -George

Attachment: exile.006.log
Description: Text Data

Attachment: interrupt-bug-hunt.diff
Description: Text Data

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

 


Rackspace

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