On Tue, 6 Jun 2000, Keith Owens wrote:
> At the end of do_nmi are these instructions
>
> outb(0x8f, 0x70);
> inb(0x71); /* dummy */
> outb(0x0f, 0x70);
> inb(0x71); /* dummy */
>
> If the NMI is for the watchdog, these instructions are bypassed.
>
> (1) Why do we need these instructions?
The AT-compatible NMI generation logic requires it. Basically IOCHK and
memory parity error lines are passed through a flip-flop each, ORed
together and then passed via a gate to CPU's NMI line. The state
of flip-flops is available via an I/O port at 0x61. Each of the
flip-flops can be reset via this port, too.
Upon servicing an NMI each of the flip-flops is checked an then reset if
set. This is performed sequentially so if another error happens in the
middle the NMI line will remain asserted. But NMI is edge-triggered so
this means it'll be stuck active forever.
Bit 7 of a port at 0x70 controls the gate that interfaces to the CPU's
NMI line. By disabling and then enabling the gate we regenerate an NMI
edge if it is active. Otherwise it's a nop. We will not recurse into the
NMI handler forever because the CPU disables further NMIs upon receiving
one until an iret instruction is executed.
> (2) Why does nmi_watchdog_tick bypass them?
The NMI watchdog does not pass through the AT control logic and it
arrives at a different APIC input. For APIC-based configurations the
AT-compatible NMI arrives at LINT1 and the NMI watchdog arrives at LINT0.
The APIC posts NMI interrupts sequentially so even if these two signals
happen to arrive at APIC inputs almost at the same time, the APIC will
generate two NMI pulses as expected.
This is not the case for 82489DX-based setups as the 82489DX treats its
PNMI output (which is connected to the CPU's NMI input) as level-triggered
but I'm not sure whether we should really care. The NMI watchdog will
work anyway (the first deassertion of either APIC inputs will deassert the
PNMI line) and AT-compatible NMIs should not appear for correctly working
systems.
-- + 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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:24 EST