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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/