Weird PCI interrupt delivery problem

[John Baldwin]

On Thursday 01 December 2005 08:31 pm, Craig Boston wrote:
> 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.

Ok.

> > 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.

Grrr.

> > 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).

That's normal.

> 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.

If an MADT exists we do use the APIC and don't use ATPICs.  That's normal.

> 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.

You shouldn't have to do that.  The ACPI standard clearly states that machines 
boot up in PIC mode by default and you only need to call _PIC to switch to 
either APIC or SAPIC (ia64) mode.  Did you disable APIC before trying the 
tunables BTW?

> 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...

Interesting.  How about IRQ 11 in non-APIC mode, is it programmed to 
level/low?  I've seen BIOSes that do very stupid things like have the link 
devices set to level/hi or edge/lo or even edge/hi.  A verbose boot should 
tell you if any settings are changed though, and in the APIC case you should 
see the initial defaults as well.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org