Re: [PATCH-2] NMI trap revised (was Re: NMI errors in 2.0.30??) (fwd)
Rik Faith (faith@cs.unc.edu)
16 May 1997 01:07:29 GMT
In article <199705150246.EAA12360@informatik.uni-koblenz.de>, linux@mailhost.uni-koblenz.de (Systemkennung Linux) writes:
|> >
|> > On Tue, 13 May 1997, Gabriel Paubert wrote:
|> >
|> > > During the NMI routine all interrupts are masked anyway, and even
|> > > NMIs are masked until the CPU executes an IRET instruction. But the
|> > > problem is printk...
|> >
|> > Not true with ix86 processors. To mask non-maskable interrupts you
|> > adjust a bit in port 0x61 (I don't have the documentation here). This
|> > is the "keyboard" chip which is really a port/uP with built-in
|> > ROM. This physically disconnects the NMI line to the processor. I
|> > think it is either bit 4 or 5. Anyway non-maskable interrupts are not
|> > maskable which means CLI and STI don't affect them. Therefore the INT
|> > bit in the flags register (which would be restored from the stack upon
|> > an IRET) does not affect it.
|>
|> Dick ist right. Hey, after all NMI stands for "Non Maskable Interrupt" ...
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.)
[Dick is talking about how to "mask" the NMI when we are *NOT* in an NMI
handler routine, and his comments have absolutely nothing to do with this
thread, which is specifically concerned with NMI handler routines.]
--
Rik Faith: faith@cs.unc.edu
"The price of reliability is the pursuit of the utmost simplicity."
--C.A.R. Hoare (1980 ACM Turing Award Lecture)