Date: Wed, 16 Oct 1996 17:48:09 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: cbrown@aracnet.com Cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <199610160948.RAA23558@spinner.DIALix.COM> In-Reply-To: Your message of "Wed, 16 Oct 1996 01:03:57 MST." <326496ED.281@aracnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Browning wrote:
> Peter Wemm wrote:
> > According to the mpspec, there is a pci->isa mapping system that is
> > supposed to "sense" when the system switches into symmetric mode and
> > disable itself when the io apics are activated. So, it depends on how the
> > ide irq's originate I guess. If they originate as "pci interrupts" that
> > go through the redirection matrix, then in theory the isa irq14/15 signals
> > should be freed up. However, Intel could well have hardwired it so that
> > the piix3 chipset generates isa edge triggered interrupts only and cannot
> > do pci-style level sensative irq's.
>
> Hmm, I'm not sure how the PIIX3 works, since I have never used a machine
> with one :-).
> As far as the mapping switching when APIC mode happens, I'm not sure
> that this happens
> automatically. The OS may have to move these where it likes.
The MPSPEC is very specific about this..
-----
D.1.1 Variable interrupt routing
In systems with variable interrupt routing, all PCI interrupts map to
EISA/ISA IRQ's when in PIC mode or Virtual wire mode. When switched to
symmetric IO mode, the system disables this routing and delivers tghe PCI
interrupts through IO APIC inputs different from those used by the
EISA/ISA IRQ's.
If IMCR is implemented, the hardware design can use this bit to
enable/disable the routing og PCI interrupts to EISA/ISA IRQ's. [..]
If IMCR is implemented but the system includes one or more IO APICS that
are not controlled through IMCR, the hardware must accomplish routing
changes by some other means when the system switches into symmetric IO
mode. These routing changes _must_ be done without requiring any
additional intervention from software.
For systems without the IMCR register, the routing if PCI interrupts to
the EISA/ISA IRQs must be automatically disabled as the IO APICS are
programmed. [..] the hardware must detect this operation and disable the
routing mechanism without additional intervention by the operating system.
-----
[I trimmed out some of the extended comments, it was too long already].
In a nutshell, this means that if we boot from an AHA2942 on pci and it's
been "mapped" into an ISA IRQ 11 (and therefore IDT number 43), once
symmetric mode is entered, the 2942 will no longer be connected to the ISA
IRQ11. It is wired up to a different input on the IO APIC somewhere.
> > > > But what does change is that you have the additional IO APIC INTS 16 th
ru
> > > > 23, 4 of which will be available for your PCI cards. Which means they w
on'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 are confusing the isa hardware interrupts with the processor's IDT
> > (interrupt descriptor table). Currently, the 16 isa interrupts are mapped
> > into IDT entries 32 through 47. With the work Steve's been doing, the IO
> > Apic's have vector numbers 32 through 55 programmed into them. So, when
> > the 8259 pics are disabled, the IO APIC produces the exact same interrupt
> > vectors, just more of them.
>
> I don't think that I am confusing these two. I understand what the IDT
> is.
> What I am saying is that the APIC bus supports 255 interrupt sources.
> In
> your system it seems that you only have one IO APIC (PIIX3) that is
> limited
> to 24 interrupts. Now, you could hook up more IO APICs and get more
> interrupts
> on the APIC bus, up to 255. For example, my system has 2 IO APICs on
> the APIC
> bus, so I can have many more than 24 interrupts on the APIC bus. Of
> course,
> most things don't take advantage of this :-(.
I was referring to your statement "interrupts 16 - 31 are reserved for
processor use". This should have been "IDT entries 16 - 31 are reserved
for processor use". We already leave these alone in the kernel and start
the isa irq's at "interrupt 32" and go up to irq15 == vector 47.
The current limitation is that when we get a vector 33 interrupt, we go
back and access the IO APIC redirection for irq-1 to mask it to prevent
recursion. This requires 1:1 mapping. Having to figure out which apic
caused the interrupt will be extra interrupt time overhead, since it's a
run-time configuration issue unlike the present dual-8259 situation where
idt vectors 32 through 39 come from PIC #1, and 40 through 47 come from
8259 PIC #2.
I've no doubt that it'll be supported, it just means that somebody has got
to sit down and figure out _how_ to glue it all together. The present
support for 24 interrupt sources from the IO apic is just arbitary. It
can go up to 28 without much pain. Beyond that is where it gets tricky
and is starting to get into 'major' design changes of the interrupt system
in the FreeBSD kernel.
BTW, sys/i386/machdep.c is where the first 32 interrupt entries are
allocated. Interrupt 0 is divide-by-zero, interrupt 1 is debugging, 2 is
the nmi vector, and so on. The "new" reserved entries from 16 - 31 are
already partly used.. 16 is the on-chip fpu, 17 is alignment, 18 is
machine check. The 486 introduced 16 and 17, the P5 had mchk, the P6
probably has more by now.
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610160948.RAA23558>