On Wed, Jun 29, 2011 at 03:55:42AM +0800, Liwei wrote:
> On 29 June 2011 03:51, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> > On Wed, Jun 29, 2011 at 03:49:07AM +0800, Liwei wrote:
> >> ----snip----
> >>
> >> Okay, that's quick...
> >>
> >> The patch's for 2.6.39 right? Seems to be slightly different in 3.0.
> >
> > Uh, it was against 3.0..
> >> May have to manually patch it.
> >
> > <nods> Should be easy enough?
> >
>
> That's weird.. looking at both Jeremy and your repos, the xen.c files
> from master and 3.0 are very different from the one the patch is based
> on.
Oh, you are using my branch! I was thinking you were using the 3.0-rc4 virgin
kernel (ie, from ftpkernel.org)
There are some cleanups in there. Try this patch instead:
commit c79ba10a5de908ae48643a9a0d74bc6da3cb4b66
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue Jun 28 15:48:38 2011 -0400
xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI
IRQ.
In the past we would use the GSI value to preset the ACPI SCI
IRQ which worked great as GSI == IRQ:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
While that is most often seen, there are some oddities:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
which means that GSI 20 (or pin 20) is to be override for IRQ 9.
Our code that presets the interrupt for ACPI SCI however would
use the GSI 20 instead of IRQ 9 ending up with:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=20
xen: acpi sci 20
.. snip..
calling acpi_init+0x0/0xbc @ 1
ACPI: SCI (IRQ9) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt
handler (20110413/evevent-119)
ACPI: Unable to start the ACPI Interpreter
as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which
got the value 9 returned. It used that value to request the IRQ 9
and since it was not preset it would fail.
The fix is to recognize that for interrupts that are overriden (in our
case we only care about the ACPI SCI) we should use the IRQ number
to present the IRQ instead of the using GSI. End result is that we get:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=9 (gsi=9)
xen: acpi sci 9
which fixes the ACPI interpreter failing.
Reported-by: Liwei <xieliwei@xxxxxxxxx>
[http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index e6ad37e..62a08d9 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -93,11 +93,29 @@ static int xen_register_pirq(u32 gsi, int triggering, bool
alloc_pirq)
name = "ioapic-level";
}
+ /* Before we bind the GSI to a Linux IRQ, check whether
+ * we need to override it with bus_irq (IRQ) value. Usually for
+ * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
+ * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
+ * but there are oddballs where the IRQ != GSI:
+ * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
+ * which ends up being: gsi_to_irq[9] == 20
+ * (which is what acpi_gsi_to_irq ends up calling when starting the
+ * the ACPI interpreter and keels over since IRQ 9 has not been
+ * setup as we had setup IRQ 20 for it).
+ */
+ if (acpi_sci_override_gsi == gsi) {
+ acpi_gsi_to_irq(gsi, &irq);
+ if (gsi != irq)
+ /* Bugger, we MUST have that IRQ! */
+ gsi = irq;
+ }
irq = xen_bind_pirq_gsi_to_irq(gsi, map_irq.pirq, shareable, name);
if (irq < 0)
goto out;
- printk(KERN_DEBUG "xen: --> pirq=%d -> irq=%d\n", pirq, map_irq.pirq);
+ printk(KERN_DEBUG "xen: --> pirq=%d -> irq=%d (gsi=%d)\n",
+ map_irq.pirq, irq, gsi);
out:
return irq;
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home