Date: Mon, 14 Oct 1996 00:26:36 -0600 From: Steve Passe <smp@csn.net> To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <199610140626.AAA29680@clem.systemsix.com> In-Reply-To: Your message of "Mon, 14 Oct 1996 06:43:20 %2B0800." <199610132243.GAA02894@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610140626.AAA29680>