Re: [PATCH-2] NMI trap revised (was Re: NMI errors in 2.0.30??) (fwd)

Gabriel Paubert (
Fri, 16 May 1997 06:31:01 +0200 (METDST)

On 16 May 1997, Rik Faith wrote:

> No. Gabriel said DURING THE NMI ROUTINE. This indicates that he is
> talking about the code in the NMI handler. I.e., an NMI has been raised,
> and we are currently IN THE NMI HANDLER ROUTINE. At this time, until the
> handler routine returns with an IRET instruction, NMI is masked BY THE
> PROCESSOR. This is exactly what Gabriel said, and he is correct, based on
> my i486 manual. (The processor masks NMI during an NMI to prevent stacking
> up calls to the interrupt handler.)
Thanks, Rik, up to now you are the only person who understands what I meant!

Actually I answered privately to all the guys who posted telling that I
was wrong to minimize noise. AFAIK this feature for preventing nested NMI was
introduced by Intel on the 286.

The only potential problem I considered up to now is that newer
processors have an SMI (system management interrupt) pin which has higher
priority than NMI. This interrupt puts the processor into system
management mode (SMM, a real mode with 4Gb segments), which can only be
exited by executing the SMM-mode only RSM (resume) instruction.

Interrupts and NMI are disabled when entering SMM mode but can be
reenabled provided an IDT for SMM is defined. Do not believe every word of
Intel's documentation and have a look at (Dr Dobb's pages if I
can remember) for more information. But anyway this will not cause
nesting of Linux's NMI handler and thus not be a concern.

BTW: To be completely transparent to OS NMI handlers, there must be
an NMI mask bit in the save state map reloaded by RSM, but AFAIK even
R.Collins does not (yet) say where it is.