Weird PCI interrupt delivery problem

[Craig Boston]

On Sat, Dec 03, 2005 at 06:41:31PM -0600, Craig Boston wrote:
> I'll keep hacking on it and follow up here if I figure anything out.

Following up, I have made some interesting progress.

With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC
case now behaves the same as the plain APIC case.  Each IRQ gets
anywhere from 10,000-500,000 interrupts before it simply stops working.

Switching the timecounter from ACPI-fast to something else after boot
also improves the situation, but not as much as disabling the timer
entirely.  Up to about 50,000 but better than the <50 it would get
otherwise.  Switching the timecounter does not bring back any IRQs that
have already "died".



Disabling the timer does not change the +ACPI -APIC case, but I've been
experimenting with that mode of operation and discovered it's not quite
as it fist appeared.  It's difficult to tell which device is producing
interrupts since they all go to IRQ 11.

I didn't notice before, but with +ACPI -APIC, the USB controller works
fine (indefinitely).  Also, I'm not 100% sure, but I don't think the
devices on pci9 are producing _ANY_ interrupts at all.  With the APIC
enabled, rl0 sometimes lasts long enough to get a lease, but with it
disabled it has yet to manage that.  Also, the irq 11 count looks too
low for multiple devices.

I compared the entire PCI configuration space for the bridge with ACPI
enabled and disabled and they were identical.  The only thing that
struck me as suspect is that the secondary status register for the
bridge has the received master abort bit set, however that happens even
when things are working so I'm not sure it's relevant.

I get the same results after "fixing" the _PRT for bus 9.  I tried both
hardcoding the interrupts to 0xb and routing them via various link
devices -- no luck.  That's all really academic; I suspect ACPI+APIC is
the only configuration that has a chance of actually working, and I'm
halfway there...

Craig