From owner-freebsd-smp Fri Jan 17 21:24:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA23238 for smp-outgoing; Fri, 17 Jan 1997 21:24:26 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA23224 for ; Fri, 17 Jan 1997 21:24:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA22187; Fri, 17 Jan 1997 22:24:00 -0700 Message-Id: <199701180524.WAA22187@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: cbrown@aracnet.com cc: smp@FreeBSD.ORG Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 20:14:57 PST." <32E04E41.5D04@aracnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 22:24:00 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > There are only four IRQ's for 5 slots. Slots 4 and 5 share the > > same IRQ. So in order to have cards in both 4 and 5, I would assume that > > the cards would have to be able to share interrupts, or one of the cards > > would just not use an interrupt. (like a video card, perhaps) This is the > > setup I have now, it seems to work fine: > > > > Slot 1: Adaptec 3940UW (IRQ 11) > > Slot 2: Matrox Millenium (IRQ 10) > > Slot 3: Empty (IRQ 9) > > Slot 4: SMC 10/100 card (IRQ 15) > > Slot 5: Empty (shares IRQ w/ slot 4) > > > > The second channel of the 3940 grabs IRQ 10, and video still works > > fine. > > Why not place the 3940UW in slot 4. That way, it will share an > interrupt with the other > channel of the 3940UW. It should be given that this card can share an > interrupt with itself. > I believe I have used this card in this configuration. Then you could > also move the Millenium to > Slot 5 and still have two empty, USABLE, PCI slots. this is the conclusion I jumped to but it (I think) wont do the trick. I believe this is what is actually done on the MB: slot1, PCI INTA -> PIRQ0 slot1, PCI INTB -> PIRQ1 slot1, PCI INTC -> PIRQ2 slot1, PCI INTD -> PIRQ3 slot2, PCI INTA -> PIRQ1 slot2, PCI INTB -> PIRQ2 slot2, PCI INTC -> PIRQ3 slot2, PCI INTD -> PIRQ0 slot3, PCI INTA -> PIRQ2 slot3, PCI INTB -> PIRQ3 slot3, PCI INTC -> PIRQ0 slot3, PCI INTD -> PIRQ1 slot4, PCI INTA -> PIRQ3 slot4, PCI INTB -> PIRQ0 slot4, PCI INTC -> PIRQ1 slot4, PCI INTD -> PIRQ2 slot5, PCI INTA -> PIRQ3 slot5, PCI INTB -> PIRQ0 slot5, PCI INTC -> PIRQ1 slot5, PCI INTD -> PIRQ2 Looking at slots 4 & 5 above you can see how a card in slot4 OR slot5 would have its PCI INTB sent to PIRQ0, effectively slot1's INTA. PIRQ# are the PCI-ISA irq redirection channels on the MB chipset. There are exactly 4 such channels on the Neptune/Triton/Natoma chipsets. These are how the PCI INTs get magically sent to the ISA bus. They have nothing to do (that I can determine) with how the PCI INTs get to the IO APIC, that (sometimes) is a different piece of silicon. For each PIRQ# there is a redirection register that can be programmed for any of the usable ISA INTs (ie NOT 0,1,2,6,8), sending the associated PCI INT to the programmed ISA INT pin (ie the 8259 channel# pin). The bottom line is that given the 4 PIRQ channels of the Neptune/Triton/Natoma chipsets you can only have 4 distinct PCI INTs on a MB when using the traditional 8259 IUCs, unless the MB maker adds additional redirection circuitry (unlikely). However the IO APIC needs no such redirection circuit and has 24 channels (Neptune only has 16) so more distinct PCI INTs could be had in such a MB. For instance my SMP board has 21: 16 ISA, 4 PCI, and a system management INT (ie green power managment). --- > Personally, I can't believe that they would design a MB with hardwired > interrupts. You should be > able to have a PCI slot without ANY interrupt assigned. In addition, > they all use INTA? That is > kinda a waste. Sounds like that kinda kludged the interrupt mapping > into the system. I don't know where this style mapping came from but it seems (in my limited knowledge) to be common on MBs these days. I suppose it was meant to make life easier for end users, not having to strap cards for specific INT pins. I would think it possible for a card maker to strap both INT[AB] of a bridged card to PCI INTA (as an option) allowing the use of only 1 PCI INT line in an OS that can handle SHARED INTs, but perhaps there is something about the PCI spec that disallows this? -- Steve Passe | powered by smp@csn.net | FreeBSD