Date: Mon, 21 Apr 2003 13:21:53 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: "Cagle, John (ISS-Houston)" <john.cagle@hp.com> Cc: freebsd-smp@freebsd.org Subject: RE: PCI devices behind bridges in APIC Full Table mode Message-ID: <XFMail.20030421132153.jhb@FreeBSD.org> In-Reply-To: <C50AB9511EE59B49B2A503CB7AE1ABD10440E4B4@cceexc19.americas.cpqcorp.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Apr-2003 Cagle, John (ISS-Houston) wrote: >> From: John Baldwin [mailto:jhb@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. Yes, -current actually has all the framework to make this work when the SMP code changes to using our pci interrupt routing framework instead of this gross hack. I am working on this but right now it is on the backburner as I work on some SMPng stuff. > 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)? Yes. Also, we have a PCI interrupt routing structure in place. Basically, we currently have 3 different PCI-PCI bridge drivers. The first is the simplest and is the 'base class' that the other drivers inherit from. It uses the swizzle to route interrupts across itself. The second is for use with UP only on i386 and uses the $PIR table to route interrupts. The third is for ACPI and uses the ACPI _PIR tables to route interrupts. However, this last doesn't work on SMP yet due to our gross hack and the way we route PCI interrupts when using an I/O APIC. > 2) Are there any plans to use ACPI for interrupt routing (like Linux is > moving to)? See above. Note that 4.x isn't going to get any of this code. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030421132153.jhb>