From owner-freebsd-hardware Fri Jun 27 04:07:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA16408 for hardware-outgoing; Fri, 27 Jun 1997 04:07:21 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA16401 for ; Fri, 27 Jun 1997 04:07:18 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA13027 (5.67b/IDA-1.5 for ); Fri, 27 Jun 1997 13:07:13 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id NAA11380; Fri, 27 Jun 1997 13:07:13 +0200 (CEST) X-Face: " Date: Fri, 27 Jun 1997 13:07:12 +0200 From: Stefan Esser To: dg@root.com Cc: Jon Inouye , freebsd-hardware@FreeBSD.ORG Subject: Re: IRQ assignment for PII motherboards References: <19970627114022.32725@mi.uni-koeln.de> <199706270959.CAA15026@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199706270959.CAA15026@implode.root.com>; from David Greenman on Fri, Jun 27, 1997 at 02:59:46AM -0700 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jun 27, David Greenman wrote: > >On Jun 26, David Greenman wrote: > >> I was able to get the Pro/100B, in a system with a pair of ahc3940's, to > >> get assigned to a non-shared interrupt by playing around with which slots > >> the cards were plugged into. It took about 3 tries to find the right order > >> (including leaving a slot empty), but I finally found an arrangement that > >> worked. My understanding is that the shared irq assignment isn't a function > >> of the BIOS, but rather a function of the slot the card is in and how it > >> is wired compared to the others. The motherboard I did this in wasn't made > >> by Intel, but the same principles should still apply. > > > >Interrupts should not be shared, unless at least one PCI card > >in the system either: > > > >1) contains a PCI to PCI bridge, or > >2) contains a multi-function PCI chip. > > Yes, the aha3940's are dual-channel SCSI adapters and have a bridge chip on > each card to connect the two SCSI chips. This seems to make the determination > of which interrupts will be shared on how they are shared very difficult or > impossible. Is there a scheme to the sharing when bridge chips are involved? Yes, sure! While the PCI BIOS knows about the wires on the motherboards (or should at least :), but can't possibly determine how the secondary bridge interrupt lines are routed to the primary side, except if there is a strict and unique rule. Well, and for that reason, this rule was introduced in rev. 2.0 of the PCI specification: Primary | Secondary IntA Sec IntB Sec IntC Sec IntD ------------------------------------------------------------------------------- IntA | Slot 0,4,8,... Slot 3,7,... Slot 2,6,... Slot 1,5,... IntB | Slot 1,5,9,... Slot 0,4,... Slot 3,7,... Slot 2,6,... IntC | Slot 2,6,10,... Slot 1,5,... Slot 0,4,... Slot 3,7,... IntD | Slot 3,7,11,... Slot 2,6,... Slot 1,5,... Slot 0,4,... I.e. for slot 0,4,8,... the PCI interrupt pins go straight through to the primary bus. IntA of slot 1,5,9,... goes to IntB on the primary side, and the rest follows if you assume circular boundaries :) A multi-function device uses IntA for function 0 and 4, IntB for function 1 and 5, and so on, and is thus identical to a PCI to PCI bridge with single function devices (which all use IntA) on slots corresponding to the function number on the secondary side. Or, viewed another way: If you assign a 0 to IntA, ... 3 to IntD, then you can just sum up modulo 4 all the secondary bus numbers, the function number and interrupt pin, and you will get the associated interrupt pin on the primary bus for some device behind an arbitrary number of PCI to PCI bridges. Again: This is required by the PCI spec., and it is the *only* way a PCI BIOS can initialize PCI interrupt routing for devices behind PCI to PCI bridges. And for this reason, card vendors tend to follow these rules! (If some card does not, it should be considered broken. The device driver may use PCI BIOS services AND its knowledge of the actual wiring to fix the interrupt routing, but I don't want to even consider adding code for that aberration :) Regards, STefan