On Tue, 20 Oct 1998, MOLNAR Ingo 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:
Ingo, I forgot to ask you - why do you say "such BIOSes violate the MP
spec"? I had a look in MP 1.4 spec and it is not clear that there should be
a bus entry in MP table for each bus. Do you (or anyone else listening)
have some reference which confirms that this is really the case?
I am aware of MP spec saying on page 4-10
"each bus is assigned a unique bus ID number by BIOS"
and then on page 4-11
"If the bus looks like a part of another bus because it uses a
subset of that bus's interrupts and address space, rendering it
totally invisible to software, it does not need its own bus entry
in the table. The two buses are then considered a single logical
bus."
Is the above enough justification? Couldn't BIOS manufacturer argue that
since the brigde does the job of mapping the address space etc by the
PCI-PCI bridge spec then the bus behind the bridge does indeed become
"totally invisible to software" in accordance with MP spec?
Maybe not... any ideas?
regards,
Tigran.
