> ... except for the fact that there _are_ motherboards which have no IRQ0
> connected to the IOAPIC, and their mptable lies about this fact. This is
> why we need mixed mode, or at least this is one of the reasons why we do
> not (yet) want to kill LINT0 based interrupts, yet.
I've already written it to you -- my patch solves this issue no matter
what the MP table tries to report of IRQ0.
> > care of EISA DMA chaining interrupts (do we?), we may set up IRQ0 as a
> > "through-8259A" interrupt which is more reliable and it needs no acking at
> > all. [...]
>
> what exactly do you mean here? To set up LINT0 as ExtINT and to unmask
> IRQ0 in the 8259A, and to mask the IOAPIC pin? Or to set up the according
Please see my patches against 2.3.13 -- the new version doesn't introduce
anything new in this matter -- just code rearrangements to fit the current
layout. Or wait till tomorrow.
> IOAPIC routing entry as ExtINT? The later one is completely pointless - if
> there is an IOAPIC pin for IRQ0 then we want that to be a LowPrio IRQ. If
Lowest priority can be done in the "through-8259A" mode and this is the
default operating mode being set by my patch when IRQ0 is not connected to
INTIN2.
> we set it up through the local APIC's LINT0 pin, then we lose the ability
> to route to multiple CPUs. (it makes no difference that the 8259A's INTR
> output signal is driven to all CPUs, there is no mechanizm to distribute
> this between CPUs, we'd get an interrupt on all CPUs at once, and had to
> do some sort of software-selection - clearly complex and suboptimal.)
If the "through-8259A" mode fails (quite possible, as the output of the
master 8259A need not be connected to any APIC either in Virtual Wire or
in PIC mode), I propose to use a "local through-8259A" mode which sets the
timer interrupt as "Fixed" to one of processors. It has the advantage of
not involving the ExtINTA trap (less circuitry means less chance for
errors, especially as the trap is a kind of a hardware hack) and getting
rid of INTA cycles on the external bus.
But instead of using a unicast "Fixed" delivery, we may use a broadcast
"NMI" (if I/O APIC can be involved), or try to broadcast through LINT0
(which need not succeed). If neither of these could be set up, we may
fall back to unicast NMI delivery and distribute NMI further using an IPI
(which is a single APIC write and is not an extreme porformance hit).
> > How would you perform this? The PC does not provide a configurable
> > delivery mode -- it's always "Fixed". And even if it would it's
>
> no, delivery mode can be configured for PCINT.
I recall it was hardwired. I'll look at the docs.
> > completely unportable -- it does not exist on i486 and Pentium systems at
> > all.
>
> and? The NMI oopser doesnt work on UP boxes either.
Well, for UP boxes it's mostly impossible to implement it (though EISA
systems used to have a second 8254 as a watchdog timer on NMI -- that
might be worthwhile to handle). But it's pretty easy to do this for SMP
systems in a compatible way. And what's more important, it would be
neither complicated nor time consuming.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/