From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 14:02:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84EE716A41F for ; Wed, 7 Dec 2005 14:02:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C41843D4C for ; Wed, 7 Dec 2005 14:02:03 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3317083 for multiple; Wed, 07 Dec 2005 09:04:05 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jB7E1rGj056645; Wed, 7 Dec 2005 09:01:58 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 7 Dec 2005 09:01:45 -0500 User-Agent: KMail/1.8.3 References: <43961758.4020407@elischer.org> <20051206.231644.34762139.imp@bsdimp.com> In-Reply-To: <20051206.231644.34762139.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512070901.47271.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: julian@elischer.org, "M. Warner Losh" Subject: Re: can someone explain...[ PCI interrupts] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2005 14:02:04 -0000 On Wednesday 07 December 2005 01:16 am, M. Warner Losh wrote: > In message: <43961758.4020407@elischer.org> > > Julian Elischer writes: > : How much is set up by the BIOS and how much is set up by the OS (4.x and > : -current). > > On 4.x, the BIOS (PCI BIOS) is called to route interrupts from the PIR > table when such a table exists. On current, ACPI routines are called > (if acpi is enabled), with a fallback to the PIR. Both use the > MPTABLE when an APIC i in voled. Actually, the MP Table is only used for !ACPI. For ACPI + APIC, you enumer= ate=20 APICs (both local and I/O) via the MADT, and for each I/O APIC, the MADT=20 specifies the IRQ cookie value of the first intpin. Then, you call the _PI= C=20 method to tell the BIOS you are using the APICs. Then, all the _PRT method= s=20 check a saved copy of that argument to _PIC and return different arrays=20 (packages in ACPI parlance) based on that, so that the _PRT's basically=20 return two different things for the two different modes. The MP Table isn'= t=20 used at all. > : In this world of multiple PCI to PCI bridges, how much latitude doe the > : OS have in > : deciding where an interrupt turns up? > : (in 4.x and -current) > > Somehwere between none and a bunch. It all has to do with what > interrupt controllers are available and how the interrupt lines are > wired. Some systems force you to use the 'barberpole' for interrupts, > while others wire them all to the same interrupts while others allow > smome limited sleections. Well, links have limited selection, everything else is hard-wired. :) > : Who is making those decisions? Is it the BIOS and 4.x is just playing > : along? > > Kinda, except when it isn't. The BIOS usually assigns an interrupt, > and we play along. However, usually is a lot less often than it used > to be so we're now more typically routing ourselves. Well, we use the BIOS set IRQs for heuristics. For example, $PIR has no wa= y=20 of telling you what IRQ given link is already routed to, so when we probe t= he=20 $PIR, we do a bunch of PCI config accesses to the IRQ register to sniff out= =20 what it looks like the BIOS has done and then use those IRQs for link=20 devices. For ACPI we do the same thing as a fallback for when _CRS on a li= nk=20 device doesn't work. This approach only works for links routed via ISA IRQ= s=20 though. For APIC routing (except for the early SMP boxes that still used=20 only ISA IRQs), the BIOS IRQ values are worthless so we ignore them. > : Linux and -current on teh same box a;;ocate way different irqs, and > : they agree about it.. i.e. Linux and -current assign my 4 port card IRQs > : 18,19,19,16. > > Resources are alloacted differently between the OS and the BIOS. > Looks like Linux has a slightly different algorithm for assigning > interrupts to free APIC pins. Notice that in all cases the middle two > are shared. That detail is likely in the MPTables for the device in > question. Linux is doing what FreeBSD 5.2+ does. :) Here what is happening is that = we=20 are doing the swizzle across the PCI-PCI bridge on the 4-port card and=20 routing on the parent sideof the bridge via ACPI or MP Table. It sounds li= ke=20 this 4-port card does something brain damaged such that the middle two=20 devices swizzle to the same INTx on the parent side of the bridge. (E.g.,= =20 the devices are at "slots" 0, 1, 5, 6 on the card instead of the more typic= al=20 0, 1, 2, 3. It could also be that it is 0, 1, 2, 3, but device 2 is using= =20 INTD rather than INTA.) =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org