Re: BIOS/ACPI interrupt conflict

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        Hello Cliff.  I think your patch does essentially the same thing as  I
did in bug kern/37538.  My original e-mail from December 2007, a full 8
months after your original patch is included below.  I too have had to keep
my laptop supplied with this patch up to at least 5.x.
Perhaps I should try yor patch to see if it has the same effect.  I think it
does.
        I note that at the time, I received strong objections to my patch on
the grounds that it didn't account for bioses which didn't setup the
interrupts and reported that they had.  That's true, but in my patch, you
had to build a custom kernel and add the option ACPI_BELIEVE_BIOS to turn it
on.  My assumption was that the problem was rare enough that most people
wouldn't need it, but for those that did, they would really need it, and
that with the patch in place, we could offer up the suggestion that they
build a custom kernel with the magic option turned on, and they'd be off to
the races.  Not ideal, but certainly better than where we are now.

-Brian

From: buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)
Date: Thu, 13 Dec 2007 22:56:33 -0800
Subject: A fix for ACPI BIOS's which route interrupts, but don't report their 
work -- was: Re: Problems with ath(4) and interrupt sharing

        Hello.  Well, it turns out that there isn't a fix in the BIOS for this
problem, but I was able to whip up a quick patch which I've submitted as
kern/37538, which allows me to use both the sound and wireless cards at
full speed with ACPI enabled.  
        The problem is that while the BIOS properly routes the interrupt for
these two devices, it doesn't actually report that the interrupt is valid
for these devices in its table.  So, when NetBSD tries to verify the
verasity of the interrupts, it can't, and so it tries to reroute the
interrupts to other irq's, with less than satisfactory results.  With this
patch, you can add
options ACPI_BELIEVE_BIOS
to your kernel config, and the kernel will just assume that what the BIOS
says is true is accurate with respect to irq assignments.
        I am by no means an ACPI expert, so if there's abetter way to achieve
this result, I'm all for it.  However, if not, then I'd like to see this
patch incorporated into the tree for NetBSD-4 and beyond, sinceI've
verified that the problem persists all the way through today's -current
sources.
        The complete bug report is available on the bug query web page, but
I'll include the patch below, since it's so short.

Comments?
-thanks
-Brian

Index: acpi_pci_link.c
===================================================================
RCS file: /cvsroot/src/sys/dev/acpi/acpi_pci_link.c,v
retrieving revision 1.7
diff -u -r1.7 acpi_pci_link.c
--- acpi_pci_link.c     24 Sep 2006 06:03:20 -0000      1.7
+++ acpi_pci_link.c     14 Dec 2007 06:03:25 -0000
@@ -369,6 +369,17 @@
 {
        int i;
 
+#ifdef ACPI_BELIEVE_BIOS
+       /*
+        *Some BIOS's route the interrupts correctly for the devices
+        *they configure, but don't report that those interrupts are valid in
+        *their interrupt table.  If this option is true, assume the BIOS
+        *did the right thing, and always return valid.
+        *Fixes interrupt problems with ACPI and the Dell D400 laptop
+        */
+       return(TRUE);
+#endif
+
        /* Invalid interrupts are never valid. */
        if (!PCI_INTERRUPT_VALID(irq))
                return (FALSE);