From owner-freebsd-smp Sun Oct 13 23:26:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01261 for smp-outgoing; Sun, 13 Oct 1996 23:26:53 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA01246 for ; Sun, 13 Oct 1996 23:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA29680 for ; Mon, 14 Oct 1996 00:26:36 -0600 Message-Id: <199610140626.AAA29680@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: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Mon, 14 Oct 1996 06:43:20 +0800." <199610132243.GAA02894@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Oct 1996 00:26:36 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > more interrupts than left by subtracting 14 and 15. > > Hmm, I read somewhere that the Triton-II HX chipset "doesn't support > interrupt steering", perhaps this is what they meant? What is the Tomcat > 2's chipset? my board (gigabyte 586DX) has the triton II and does what I would call semi-automatic INT steering, specifically from the AWARD BIOS I can assign each INT as: "disabled": never tried, guess it is a "hard mask" "legacy ISA": PCI leaves it alone "PCI/ISA PnP": BIOS uses some unknown (to me) algorithm to pick INTS from any of these. > The other "interesting" news is that the mpspec1.4 compliant motherboards > are supposed to have the PCI interrupts wired to different APIC interrupt > inputs. The IO APIC chipset that goes with the T2-HX pciset and friends > has 24 interrupt inputs, of which the first 16 typically go to the ISA > bus, the next 4 go to the PCI bus, and the spares are used for other > things like SMI and so on. > > With the work that Steve's been doing on the IO APIC stuff to get it > running in full symmetric IO mode (rather than virtual wire), this > restriction should become only a bootstrap problem. Once the system is > running fully symmetric, you have a total of 20 interrupts available. The theoretical limit is 24, on mine I have 21: 1 cascade of MASTER 8259 INTR out (not used in symmetric mode). 15 ISA. (8259 SLAVE out has no meaning) 4 PCI. 1 SMI (System Management INT) > IDE interrupts will disappear from irq-14 and 15 once it's switched to > symmetric mode, so if you have smart cards in there that have programmable > irq's, those will be available for assignment shortly after boot. Once I'm not sure about this, from what I've seen in the tyan news group, I think they may have REALLY tied those suckers down to IRQ-14/15. and thus I would expect them to be directly tied to IO APIC INTs 14/15. There may be nothing programmatic that you can do to free them up for other use. But what does change is that you have the additional IO APIC INTS 16 thru 23, 4 of which will be available for your PCI cards. Which means they won't have to compete with ISA cards for the 1st 16 INTS. And they are direct, active low, level triggered INTs (if so programmed), so they should be sharable (although sharing will require additional code changes). It's my hope that the PCI INTs will be "free-able", but even that may be a vendor specific issue. The bottom line is that it SHOULD be do-able, but you are still at the mercy of your motherboard's design. > irq's, those will be available for assignment shortly after boot. Once > the pci code has been "taught" about interrupts that change after bootup > and when to ignore the irq mapping registers, it should be nice. There's STefan has said he will give me the necessary changes in pci.c to make that last restriction go away within a few days. If he can't get to it by next week, I have an idea for making my current "PCI bandaid" automatic as oppossed to hardcoded, so there will be a fix soon either way. At that point the kernel should be usable in ISA/EISA/PCI boards with native IO APIC code in effect (but you won't be able to use EISA boards yet, there is something going on with them that is still to be determined). > a lot of hard coded stuff at the moment that suits Steve's particular > machine though, for some strange reason. ;-) very little anymore. the last round of commits I did remove all the hardcoded numbers EXCEPT those for the PCI bus. Each IO APIC pin is programmed according to the declared use in the MP table, including edge/level, hi/lo, etc. Some of this is a little murky, as the table may say "conforms to specifications of the bus" which is not necessarily an absolute. The 8254 and the rtc clock vectors are both programmatically determined and setup according to the MP table. I have NOT gotten to look at vmxxx stuff yet so things that gather statistics thinking the clock is on INT0 may be flakey! But the critical stuff in vector.s, icu.s, etc are now all doing "the good thing". -- Steve Passe | powered by smp@csn.net | FreeBSD