PCI devices behind bridges in APIC Full Table mode

[Cagle, John (ISS-Houston)]

> From: John Baldwin [mailto:jhb at FreeBSD.org] 
> On 18-Apr-2003 Cagle, John (ISS-Houston) wrote:
> > With 4.8-stable, I'm having a problem with IRQ routing when 
> a device 
> > is behind a PCI-to-PCI bridge in a PCI slot (like a dual-port NIC), 
> > when using APIC "full-table" mode.  It appears that the 
> kernel is not 
> > looking at the mptable to determine the proper interrupt 
> pin routing 
> > for these devices.
> > 
> > Does anyone know if FreeBSD has support for this?  Can 
> someone direct 
> > me to the area of the kernel to examine?
> 
> Eyuck.  The APIC PCI interrupt routing is a hack in 4.x (and 
> still is in current as well).  It is spread between 
> sys/i386/i386/mpapic.c and this evilness in sys/pci/pci.c:

John,

Here's what I would suggest to add support for PCI-to-PCI bridges in
slots:

In mpapic.c, if pci_apic_irq() can't find the bus/device in the mptable,
it needs to look for the device's upstream PCI bridge (if there is one)
and search for that in the mptable.  If that bridge isn't found, then it
needs to keep going upstream (to the next PCI bridge) until it finds a
bus/device listed in the mptable.  If it does ever find an upstream
bridge, then it will need to swizzle the intpin (barber-pole), according
to the rules of PCI, to determine the real intline for the device in
question.

Questions:

1) Is there any code/data structure already in place that enumerates the
PCI busses in the system (including those behind PCI-to-PCI bridges in
slots)?

2) Are there any plans to use ACPI for interrupt routing (like Linux is
moving to)?

Thanks,
John

--------------------------------
John Cagle     john.cagle at hp.com
Principal Member Technical Staff
   Industry Standard Servers
    Hewlett-Packard Company