From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 14:40:47 2004 Return-Path: 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 90ED716A4CE; Fri, 2 Jan 2004 14:40:47 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A6943D39; Fri, 2 Jan 2004 14:40:38 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i02MeQN1028032 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 2 Jan 2004 23:40:29 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i02MeHMO060930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2004 23:40:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i02MeGBE021091; Fri, 2 Jan 2004 23:40:16 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i02MeGpI021090; Fri, 2 Jan 2004 23:40:16 +0100 (CET) (envelope-from ticso) Date: Fri, 2 Jan 2004 23:40:16 +0100 From: Bernd Walter To: John Baldwin Message-ID: <20040102224015.GI17023@cicely12.cicely.de> References: <20040102195244.GE17023@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: Bernd Walter cc: ticso@cicely.de cc: current@FreeBSD.org Subject: Re: Still IRQ routing problems with bridged devices. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 22:40:47 -0000 On Fri, Jan 02, 2004 at 04:30:44PM -0500, John Baldwin wrote: > > On 02-Jan-2004 Bernd Walter wrote: > > On Fri, Jan 02, 2004 at 02:19:53PM -0500, John Baldwin wrote: > >> On 01-Jan-2004 Bernd Walter wrote: > >> > On Thu, Jan 01, 2004 at 10:12:23AM -0700, M. Warner Losh wrote: > >> >> In message: <20040101155100.GF11668@cicely12.cicely.de> > > I have no clue about $PIR and therefor have no idea where irq4 comes > > from - any pointer to $PIR documents are welcome. > > Erm, according to the PCI spec, the devices behind the bridges on the > add-in cards will swizzle their interrupts. Thus, device 8.0 will > use INTA on the add-in card's connect, 9.0 will use INTB for its > INTA, etc. We use the $PIR to then figure out what IRQ to use for > INT[ABCD] on that slot as appropriate. Thus, it would work something > like this: > > 1) device 1.8.0 wants to route INTA so it asks the bridge for the IRQ > 2) the bridges translates that into INTA on itself, and asks its parent > for a route to INTA at its slot (say 0.2.0). Yes - I know how PCI bridge routing works. What I don't know is the x86 sepcific evilness. > 3) the host bridge lookes up 0.2.0 INTA in the $PIR, chooses an IRQ from > the possible list (defaults to just using first IRQ) and returns it. > This step should be skipping IRQ 4 adn using IRQ 10 or 11 instead That's the interesting part. What exactly is in the $PIR table? Fact is that the 4 PCI connectors share the same intlines wired in different INTA-D order which is board specific. The intlines are setup by the BIOS to 5, 10, 11 and 12. Now FreeBSD has found out that it needs 0.2.0 INTA for the bridged device 1.8.0 INTA. It now incorrectly selects IRQ4 for 0.2.0 INTA, which is already in use for a ISA device by an PnP On-Board component. It also has to connect the intline with IRQ4 anywhere in the chipset, which doesn't seem to happen, because the IRQ doesn't even work. And I don't see the point why this is not a problem for non bridged devices, which would also require an IRQ for 0.2.0 INTA. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de