From owner-freebsd-smp@FreeBSD.ORG Mon Apr 21 10:21:55 2003 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D72237B404 for ; Mon, 21 Apr 2003 10:21:53 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C3F643FA3 for ; Mon, 21 Apr 2003 10:21:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5023 invoked from network); 21 Apr 2003 17:21:56 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 21 Apr 2003 17:21:56 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3LHLnOv090313; Mon, 21 Apr 2003 13:21:49 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 21 Apr 2003 13:21:53 -0400 (EDT) From: John Baldwin To: "Cagle, John (ISS-Houston)" cc: freebsd-smp@freebsd.org Subject: RE: PCI devices behind bridges in APIC Full Table mode X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:21:56 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/