Date: Mon, 14 Oct 1996 21:19:38 -0700 From: Chris Browning <cbrown@aracnet.com> To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <326310DA.2A9B@aracnet.com> References: <199610140626.AAA29680@clem.systemsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe wrote: > 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" That sounds right. It probably mask out that interupt in which ever devices is providing the 8259 compatibility. > "legacy ISA": PCI leaves it alone > > "PCI/ISA PnP": BIOS uses some unknown (to me) algorithm to pick INTS from > any of these. This setting allows the BIOS to choose the interrupt based on PCI/PnP. I think that typically, the BIOS will try to give the card the same interrupt it requested last time. When a card (PCI atleast) is installed in the system, it request an interrupt from the BIOS. The BIOS will typically give the card this interrupt, unless there is another device on that interrupt that doesn't support interrrupt sharing. Now this can vary greatly depending on how the BIOS is implemented. > > The other "interesting" news is that the mpspec1.4 compliant motherboards > > are supposed to have the PCI interrupts wired to different APIC interrupt > > inputs. I think this is true for MP Spec 1.1 also. > > 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. Yes, this is certainly the way to go. > > 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: Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium (TM) Pro Family Developers Manual, Volume 3 is 255. I believe this is standard for all system implementing the APIC bus. Now, your motherboard may limit you to less, but not the APIC bus. > 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 Hmm, I'm not sure if this is true by default. Unless the OS goes in and moves those devices, they will stay where they are. > 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. I agree. IDE is typically hardwired to INT 14 (and i guess 15 for EIDE from what you say). I don't know if drivers, BIOS, etc will find an IDE device elsewhere. > 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. Wrong. According to the same page I quoted above, interrupts 16-31 are reserved for processor use. This may be different on a non PPro system. 32-255 are available for general purpose use. Now, from an OS prespective, you may never see 16-31 and the rest may get shifted down, since this is all done in HW. You will have to compete for the ISA interrupts still, unless you have a lot of PCI devices you don't want to be visible at boot time (i.e. moving your super-fancy SCSI card to an interrupt above 15 will mean you can't see it until you get into the OS) > And they are direct, active low, level triggered INTs (if so programmed), > so they should be sharable (although sharing will require additional > code changes). Hmm, it would be good to add this. Things get pretty limited these days without sharing interrupts. Of course, all the drivers will have to be rewritten if they can't handle shared interrupts. > 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 -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJSHeUAAAEEAKQrvftlb+sbnw0hA5vW2Orzq3rCGypldkYxRdXhx0yWx/dY U2PMqxgTwlOeQl3wA1IIWGMaHhbpPp0IegkOm9HIHEvc2G8uWywN5OvkaVFyuIHL juZ6VSem3cd63bqpNe3ZWtWwQdjFivm+YNeQveV220eTPfTuvbz7xZq+b9WZAAUR tCtDaHJpcyBTaGVybWFuIEJyb3duaW5nIDxjYnJvd25AYXJhY25ldC5jb20+ =NxsF -----END PGP PUBLIC KEY BLOCK-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?326310DA.2A9B>