IRQ problem with IO-APIC and plx9056-based data capture board

IRQ problem with IO-APIC and plx9056-based data capture board

[Brett Boren]

I have a plx9056-based data capture board that works with the winXP
drivers (based off of the win32 plx sdk) but does not work with the
linux driver provided to me. The board constitently gets 0xa (IRQ 10)
in the INTERRUPT_LINE register but the IO-APIC reports IRQ 49 to the
kernel. To add to the confusion when an interrupt is triggered it
arrives on IRQ 17 causing an irq disable. When run with `noapic` on
the kernel bootline a consistent irq 10 is observed and the driver
behaves correctly. When `irqpoll` is given the driver behaves
correctly(kernel complains about irq 10 being the registered irq
handler) though it causes other kernel problems. The following options
have been tried in isolation with no success: pci=nommconf; pci=conf2
(noboot); acpi=bigsmp; pci=routeirq (kernel output changes, but no
change in behavior); pci=noacpi acpi=noirq (seems identical to
pci=routeirq); acpi=irq_balance; apic=debug.

I'm running primarily in a Dell precision 370n workstation with 3
PCI-X slots. The irq reported in by the IO-APIC changes depending on
which slot I plug it in.

Slot       INTERRUPT_LINE     IO-APIC        Observed
1           10                            49                 17
2           10                            53                 17
3           9                              26                 18

The same general behavior has been observed in _every_ linux machine
I've been able to plug this card into that had an IO-APIC. These were
mostly Intel chipsets but I 've also had it in a Tyan 8-proc AMD board
with a Nvidia chipset with the same interrupt issues.

I see two problems: first, the INTERRUPT_LINE register on the card is
not consistent with either the APIC reported irq or the actual irq.
Second, that the IO_APIC, which is supposed to maintain a mapping of
its pins to a particular irq, is inconsistent in what IRQ is reported
for a particular pin (different slots result in different irqs
reported, but still actually use irq 17).

I'm not a LKML subscriber so please CC to brett.boren_at_gmail_dot_com.

Thanks,
Brett

Re: IRQ problem with IO-APIC and plx9056-based data capture board

[Robert Hancock]

Brett Boren wrote:
> I have a plx9056-based data capture board that works with the winXP
> drivers (based off of the win32 plx sdk) but does not work with the
> linux driver provided to me. The board constitently gets 0xa (IRQ 10)
> in the INTERRUPT_LINE register but the IO-APIC reports IRQ 49 to the

You should not be looking at PCI_INTERRUPT_LINE at all. That is set by 
the BIOS and applies only for XT-PIC interrupt routing, not for IOAPIC. 
It is not necessarily relevant to the interrupt numbers used by Linux at 
all.

> kernel. To add to the confusion when an interrupt is triggered it
> arrives on IRQ 17 causing an irq disable. When run with `noapic` on
> the kernel bootline a consistent irq 10 is observed and the driver
> behaves correctly. When `irqpoll` is given the driver behaves
> correctly(kernel complains about irq 10 being the registered irq
> handler) though it causes other kernel problems. The following options
> have been tried in isolation with no success: pci=nommconf; pci=conf2
> (noboot); acpi=bigsmp; pci=routeirq (kernel output changes, but no
> change in behavior); pci=noacpi acpi=noirq (seems identical to
> pci=routeirq); acpi=irq_balance; apic=debug.
> 
> I'm running primarily in a Dell precision 370n workstation with 3
> PCI-X slots. The irq reported in by the IO-APIC changes depending on
> which slot I plug it in.
> 
> Slot       INTERRUPT_LINE     IO-APIC        Observed
> 1           10                            49                 17
> 2           10                            53                 17
> 3           9                              26                 18
> 
> The same general behavior has been observed in _every_ linux machine
> I've been able to plug this card into that had an IO-APIC. These were
> mostly Intel chipsets but I 've also had it in a Tyan 8-proc AMD board
> with a Nvidia chipset with the same interrupt issues.
> 
> I see two problems: first, the INTERRUPT_LINE register on the card is
> not consistent with either the APIC reported irq or the actual irq.
> Second, that the IO_APIC, which is supposed to maintain a mapping of
> its pins to a particular irq, is inconsistent in what IRQ is reported
> for a particular pin (different slots result in different irqs
> reported, but still actually use irq 17).
> 
> I'm not a LKML subscriber so please CC to brett.boren_at_gmail_dot_com.

You should only be using the interrupt which is listed in the irq member 
of the struct pci_dev for your device. Likely if you do that your 
problems will go away.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/