Doing this for Len, who is on vacation. We would like to thank the
people who provided debugging info such as acpidmp, dmidecode, and
demsg. This is one of our findings, and we believe this would fix some
interrupt problems (with USB, for example) with ACPI enabled, especially
when the dmesg reads like:
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0
ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0
Basically we assumed that _CRS returned the one we set with _SRS, when
setting up a PCI interrupt link device, but that's not the case with
some AML codes. Some of them always return 0.
Attached is a patch against 2.4.23-pre1. It should be easy to apply this
to 2.6.
Thanks,
Jun
___
diff -ru /build/orig/linux-2.4.23-pre1/drivers/acpi/pci_link.c
linux-2.4.23-pre1/drivers/acpi/pci_link.c
--- /build/orig/linux-2.4.23-pre1/drivers/acpi/pci_link.c
2003-08-25 04:44:41.000000000 -0700
+++ linux-2.4.23-pre1/drivers/acpi/pci_link.c 2003-08-29
20:21:13.000000000 -0700
@@ -216,7 +216,6 @@
return AE_CTRL_TERMINATE;
}
-
static int
acpi_pci_link_get_current (
struct acpi_pci_link *link)
@@ -275,6 +274,26 @@
return_VALUE(result);
}
+static int
+acpi_pci_link_try_get_current (
+ struct acpi_pci_link *link,
+ int irq)
+{
+ int result;
+
+ result = acpi_pci_link_get_current(link);
+ if (result && link->irq.active) {
+ return_VALUE(result);
+ }
+
+ if (!link->irq.active) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "No active IRQ resource
found\n"));
+ printk(KERN_WARNING "_CRS returns NULL! Using IRQ %d for
device (%s [%s]).\n", irq, acpi_device_name(link->device),
acpi_device_bid(link->device));
+ link->irq.active = irq;
+ }
+
+ return 0;
+}
static int
acpi_pci_link_set (
@@ -359,7 +378,7 @@
}
/* Make sure the active IRQ is the one we requested. */
- result = acpi_pci_link_get_current(link);
+ result = acpi_pci_link_try_get_current(link, irq);
if (result) {
return_VALUE(result);
}
@@ -573,10 +592,6 @@
else
printk(" %d", link->irq.possible[i]);
}
- if (!link->irq.active)
- printk(", disabled");
- else if (!found)
- printk(", enabled at IRQ %d", link->irq.active);
printk(")\n");
/* TBD: Acquire/release lock */
* Nakajima, Jun ([email protected]) wrote:
> Doing this for Len, who is on vacation. We would like to thank the
> people who provided debugging info such as acpidmp, dmidecode, and
> demsg. This is one of our findings, and we believe this would fix some
> interrupt problems (with USB, for example) with ACPI enabled, especially
> when the dmesg reads like:
>
> ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0
> ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0
> ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0
> ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0
>
> Basically we assumed that _CRS returned the one we set with _SRS, when
> setting up a PCI interrupt link device, but that's not the case with
> some AML codes. Some of them always return 0.
> Attached is a patch against 2.4.23-pre1. It should be easy to apply this
> to 2.6.
This patch wouldn't compile with CONFIG_ACPI_DEBUG=y (I'm using
2.6.0-test4-mm5). Simple fix below. With this patch my machine is worse
off than without it. In either case the machine hangs during boot (not
in the same place, of course). And booting with pci=noapci works w/out
the patch, but leaves the machine nearly disfunctional w/ the patch.
Any particular information helpful?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--- 2.6.0-test4-mm5/drivers/acpi/pci_link.c.try Wed Sep 3 15:06:33 2003
+++ 2.6.0-test4-mm5/drivers/acpi/pci_link.c Wed Sep 3 15:07:22 2003
@@ -285,6 +285,8 @@ acpi_pci_link_try_get_current (
{
int result;
+ ACPI_FUNCTION_TRACE("acpi_pci_link_try_get_current");
+
result = acpi_pci_link_get_current(link);
if (result && link->irq.active) {
return_VALUE(result);
On Wednesday 03 September 2003 23:37, Chris Wright wrote:
> * Nakajima, Jun ([email protected]) wrote:
> > Doing this for Len, who is on vacation. We would like to thank the
> > people who provided debugging info such as acpidmp, dmidecode, and
> > demsg. This is one of our findings, and we believe this would fix some
> > interrupt problems (with USB, for example) with ACPI enabled, especially
> > when the dmesg reads like:
> >
> > ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0
> > ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0
> > ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0
> > ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0
> >
> > Basically we assumed that _CRS returned the one we set with _SRS, when
> > setting up a PCI interrupt link device, but that's not the case with
> > some AML codes. Some of them always return 0.
> > Attached is a patch against 2.4.23-pre1. It should be easy to apply this
> > to 2.6.
Wow! This is exactly the idea I've just come up with for VIA boards!