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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux