Weird PCI interrupt delivery problem

[Craig Boston]

On Thu, Dec 01, 2005 at 01:42:18PM -0500, John Baldwin wrote:
> Yeah, odd, no $PIR.  You can get your cbb0 to work though using a tunable in 
> the loader.  Something like:
> 
> hw.pci9.1.INTA.irq=11

That does fix cbb0.  With that line, the cardbus works in plain-old-PIC
mode.

I suspect that really old 16-bit PCMCIA cards with non-sharable
interrupts wouldn't work, but does NEWCARD even support those anyway?

> should do the trick to get your box working in the !ACPI and !APIC case at 
> least and you can see if it has the same issue with freezing up then.

So far it seems to be working fine with !ACPI !APIC and that tunable.
I'm pingflooding some "volunteers" on the wired and wireless LANs, and
transferring 16MB/s from an external drive over firewire (cardbus fwohci).

So far it's been running for about 30 minutes with a sustained interrupt
rate of ~6000.  That would be more than enough to kill it in the plain
APIC (no ACPI) case.

Still, this thing doesn't have apm so if I want any sort of power
management I'll need to figure out why ACPI & APIC are broken.

> For a test, you can try compiling cbb out of your kernel and seeing if
> the box works ok.

No luck, still fails exactly the same in ACPI mode with cbb removed from
the kernel.

> That's cbb0 and it has no address assigned to BAR 0x10 (nor an IRQ).

Unfortunately the BIOS is no help here either -- the only thing
configurable is the boot order...

> I'd still be interested to hear how the broken kernels fair if you
> take cbb out and how the 8259 kernel does with the variable set to fix
> cbb0's interrupt.

All 3 (broken) combinations of ACPI and APIC behave exactly the same
with cbb/pccard/cardbus removed from the kernel. :(

> You could also try moving one of the links to IRQ 10 in the ACPI case
> via a tunable such as:

> hw.acpi.LNKA.irq=10 or some such (can't recall if that's the right
> name).

Looks like it's hw.pci.link.LNKA.irq.  However, there are a couple
problems:

1. The ASL for this machine expects to be notified of the interrupt
model via the _PIC method.  It changes the _PRT depending on which model
is in use.  For APIC, it doesn't use the PCI link objects at all and
just hardcodes all the vectors.  For PIC, it uses the LNK objects (which
are constrained to IRQ 10 or 11).

If I'm reading the code correctly, it appears that we call _PIC and set
the interrupt model to APIC, *if an MADT table exists*, regardless if
we're actually using the I/O APIC or not.  This is what initially had me
thinking ACPI/PIC wasn't supported at all.

2. I "solved" the previous problem by modifying the ASL to assume PIC
mode, and then the tunables started working.  It was only able to move
devices on the "near" side of the bridge (i.e. on pci0), but they did
work briefly on IRQ 10 before freezing just as before.

I think this is unrelated to my problem, however, as I get the same
behavior both with and without that modification (but it may be a bug
that needs to be fixed).

Argh, this is driving me up the wall.  I had a hunch that it was somehow
connected to level-triggered interrupts.  That seems to not be the case,
as upon closer inspection the SCI interrupt (9) gets reprogrammed to
level/low.  I can read the ACPI status all day long and the count for
IRQ 9 goes up and up without freezing...

Craig