I'm diagnosing a PCI IRQ problem on a Tyan S5112 motherboard. I pushed
it back to where the kernel builds it's IRQ maps in
arch/i386/kernel/mpparse.c (2.4.32 kernel). (The Tyan S5112 has a
seperate IO APIC for it's PCI-X bus.)
What I found was for a board on the PCI-X bus the MP data read in
mpparse.c says that the board has IRQ 16 on APIC #2. By trial and
error I've determined that in fact the board is on IRQ 3 on APIC #3.
(APIC IDs are the physical IDs reported from the APIC registers: #2 ==
first APIC, #3 == second APIC.)
Questions/advice:
1. I infer that the motherboard bios has a bug in it's irq map build.
Is this a reasonable conclusion?
2. I see various hacks in pci-irq.c to patch up erroneous IRQ
assignments. However, it's not clear to me that the code in
pci-irq.c:pcibios_lookup_irq() will work with IO APICs enabled. What's
the best way to write a patch for this motherboard, to do the IRQ
remapping discovered above? A pointer to an example in the kernel
source would be helpful; I haven't stumble on such yet.
3. The board I'm debugging has several distinct functions and
associated drivers and IRQ service routines. The interrupts for the
different functions are asserted on different PCI pins: A, B & C. Yet,
all the interrupts come in on the same IRQ I discovered above, namely
IRQ 3 on APIC #3. Is this board just or-ing all the interrupt pins
together, or do IO APICs handle this situation differently? (I've not
found any good docs or refs on PCI pin mapping for IO APIC based
boards.)
Any help/advice/links are appreciated.
Rod
[email protected]
-
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]
