On Wed, Apr 07, 2004 at 12:08:59AM -0400, Brown, Len wrote:
> >I'm assuming that it is not the fault of either of these drivers, since
> >both of those are quite straightforward; they appear to be actually
> >being triggered when nothing is going on.
> 
> If IRQ initialization is done incorrectly, it is possible
> For a driver to request_irq(X), while the hardware is actually
> on IRQ Y.
> 
> Then when that device becomes active, it would kill the other
> devices on Y because its handler is looking for interrupts on X.
> 
> If this happens with acpi enabled, but doesn't happen with acpi=off
> or pci=noacpi, then we need to compare the /proc/interrupts between
> the working and failintg configs to see if the IRQs have moved around
> when perhaps they should not have.  Dmesg from the ACPI case would
> also be needed.

Thanks for your continued help... this gave me some extremely
interesting data.  Here's some data from /proc/interrupts on
2.6.0-test9, which was quite stable for me:
 19:          0          0   IO-APIC-level  au88xx
 21:         52          0   IO-APIC-level  uhci_hcd, uhci_hcd

2.6.5 with ACPI:
 11:     300000          0   IO-APIC-level  uhci_hcd, uhci_hcd
 19:     299999          1   IO-APIC-level  au8830

2.6.5 with pci=noacpi:
  5:         54          1   IO-APIC-level  uhci_hcd, uhci_hcd, au8830

I haven't run that third setup for a lot of time yet, so I don't know
for sure that it's stable.  Sound seems much more crackly than it was
with ACPI enabled, but that could be any problem with the vortex2
driver - or it could be missing interrupts.

Here's one interesting bit that only appears in dmesg with ACPI
enabled, and only in 2.6.5:

PCI: Via IRQ fixup for 0000:00:07.2, from 5 to 11
PCI: Via IRQ fixup for 0000:00:07.3, from 5 to 11

That's the two UHCI devices.  So they get quirked off to a different
IRQ, and au88x0 somehow ends up routed to yet a third IRQ, but from the
symptoms I am guessing that the USB and au8830 are actually connected
to the same pin.  That would explain both of them getting interrupts
with no obvious source, even though they do each get their own
interrupts also.

The quirk isn't new; it's from 2002.  So presumably ACPI is now putting
them somewhere different than it used to.  Here's a some bits of the dmesg:

2.6.0-test9

ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
IOAPIC[0]: Set PCI routing entry (2-11 -> 0xc9 -> IRQ 27 Mode:1 Active:1)
00:00:07[A] -> 2-11 -> IRQ 27
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 12
IOAPIC[0]: Set PCI routing entry (2-12 -> 0xd1 -> IRQ 28 Mode:1 Active:1)
00:00:07[B] -> 2-12 -> IRQ 28
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
IOAPIC[0]: Set PCI routing entry (2-10 -> 0xd9 -> IRQ 26 Mode:1 Active:1)
00:00:07[C] -> 2-10 -> IRQ 26
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
IOAPIC[0]: Set PCI routing entry (2-5 -> 0xe1 -> IRQ 21 Mode:1 Active:1)
00:00:07[D] -> 2-5 -> IRQ 21

2.6.5

ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
IOAPIC[0]: Set PCI routing entry (2-11 -> 0x81 -> IRQ 11 Mode:1 Active:1)
00:00:07[A] -> 2-11 -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
IOAPIC[0]: Set PCI routing entry (2-10 -> 0x79 -> IRQ 10 Mode:1 Active:1)
00:00:07[B] -> 2-10 -> IRQ 10
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11


I've attached the dmesgs and /proc/interrupts.



In the interest of full disclosure, this motherboard came with a bad
_PRT.  There are a four entries in the APIC-mode _PRT which look like:
            Package(0x4) {
                0x0007ffff,
                0x0,
                0x0,
                \_SB_.PCI0.LNKA,
            },

With that, ACPI complains and/or can't boot (don't remember exactly). 
So I've fudged them to:
            Package(0x4) {
                0x0007ffff,
                0x0,
                \_SB_.PCI0.LNKA,
                0x0,
            },

I made this change some months before the 2.6.0-test9 kernel which
worked OK.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer