From owner-freebsd-smp Thu Dec 5 16:02:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA13595 for smp-outgoing; Thu, 5 Dec 1996 16:02:51 -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 QAA13590 for ; Thu, 5 Dec 1996 16:02:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA15873; Thu, 5 Dec 1996 17:02:15 -0700 Message-Id: <199612060002.RAA15873@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: clintw@colorado.cirrus.com (Clint Wolff) cc: smp@freebsd.org Subject: Re: make locking more generic? In-reply-to: Your message of "Thu, 05 Dec 1996 16:32:52 MST." <9612052332.AA02586@longs.colorado.cirrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Dec 1996 17:02:15 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hi, > > > We still have the problem with two (say, adaptec SCSI) devices > > > on different IRQs vs two different devices on the same IRQ. > > > > > > This is why multiple I/O APICS would be great -- each device > > > gets it own unique IRQ. Then the OS can play games redirecting > > > IRQs for processor affinity interrupt handling, better load > > > (IRQ) ballancing, etc. > > > > multiple controllers can use unique PCI IRQs, IF the manufacturer designs > > the motherboard correctly, all on 1 IO APIC. Or the MB manufacturer > > can ignore those extra IRQs on the IO APIC and "redirect" PCI IRQs > > to traditional ISA IRQs. doing the kernel to account for all these > > "design considerations" that the various boards throw our way make it > > even more challenging! > > > > > > Perhaps I am not understanding this all, but my SCSI controller (AHA-2940) > and my Ethernet controller (SMC EtherPower?? DEC PCI chipset) BOTH want > to be on INTA... Doesn't this mean they are both handled by the same IRQ? > > A side note of this is, multiple AHA-2940s would all be on the same IRQ also... > > Or is there some nuance of the PCI bus I am missing here.... yes there is, but not sure I can explain properly. my mptable: I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0 2 0 INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 >>> INT active-lo level 1 8:A 2 16 >>> INT active-lo level 1 9:A 2 17 >>> INT active-lo level 1 10:A 2 18 >>> INT active-lo level 1 12:A 2 19 SMI conforms conforms 0 0 2 23 note how the 4 PCI IRQs are all on INTA, but different PCI devices, and get directed to different APIC IRQs (16,17,18,19). my dmesg shows: de0 rev 17 int a irq 16 on pci0:8 ^ ^^ ^ ahc0 rev 0 int a irq 19 on pci0:12 ^ ^^ ^^ note that the de0 would have been redirected to ISA IRQ10 and the ahc0 would have been redirected to ISA IRQ11 on the standard kernel. The SMP kernel parses the mp table info and decides it can program the IO APIC to use these upper INTs (and eventually I'll reprogram the MD chipset to "undirect" the ISA INTs allowing other ISA cards to use them!) A few simple changes to pci.c and PCI INTs now appear on APIC IRQs 16-19. unfortunately not all MB manufacturers do it this way, often using the "redirected" ISA INTs, completely ignoring APIC pins 16-23.... for some more insight on just how different these motherboards can be check out the database of mp tables on: http://www.freebsd.org/~fsmp/SMP/mptable/mptable.html -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----