On Tue, 20 Oct 1998, Tigran Aivazian wrote:
> The pcibios_fixup_devices() (of 2.1.125) does this:
>
> irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
>
> and the IO_APIC_get_PCI_irq_vector() only does the job if the bus number
> matches the srcbus field of the corresponding IO interrupt entry in MP
> table. Now, imagine that you have a plugin card with PCI-PCI bridge on
> it and a device downstream, whose PCI header in config space was
> initialised (by PCI BIOS) with PCI_INTERRUPT_LINE value corresponding to
> a not-connected pin of IO-APIC as would be mapped by pin_2_irq() of
> arch/i386/kernel/io_apic.c. Also, the MP BIOS will be unaware of that
> card [...]
such BIOSses violate the MP spec. But yes, it happens :( This is a 'known'
errata as far as i know. Support for bridged PCI buses is one of the main
additions in MP spec 1.4. Your BIOS is MP 1.4:
<4>Scan SMP from c0000000 for 1024 bytes.
<4>Scan SMP from c009fc00 for 1024 bytes.
<4>Scan SMP from c00f0000 for 65536 bytes.
<4>Intel MultiProcessor Specification v1.4
> and prepare a nice MP table with only entries for the "onboard" PCI
> buses (see mptable and /proc/pci below). Then pcibios_fixup() will not
> fix it and leave it with the value unmanageable by IO APIC. Then a
> device driver comes along and trusts the dev->irq value enabling irq
> which never occurs.
yep.
> Is this really bad or am I paranoid? It would be better if I knew how to
> fix it... But I think one could enhance IO_APIC_get_PCI_irq_vector() to
> not give up if the busid does not match but check if we are behind a
> bridge and go back closer to the buses listed in MP table (swizzling the
> pin along the way in the manner of PCI-PCI bridge spec), where the
> current version of IO_APIC_get_PCI_irq_vector() works fine.
i too think this is a real issue. But i think this should be a 'PCI
quirk'. The fix could be to find the root entry of the PCI bus tree and
call a second IO_APIC_get_PCI_irq_vector() for this device entry. If this
fails too then use the original (unmapped) PCI line, if it succeeds then
print a warning and use the "owner device's" irq line.
unfortunately i do not have any such card, if you feel like trying to
implement this i'd be glad to comment on your patch. It's a definit
problem to be solved. A few months ago somone reported a similar problem,
Adaptec SCSI cards do multichannel support via PCI bridges too. (and
multi-interface Ethernet cards too)
Ingo
