Path: utzoo!utgpu!attcan!uunet!husc6!cs.utexas.edu!natinst!bigtex!james
From: james@bigtex.cactus.org (James Van Artsdalen)
Newsgroups: comp.sys.ibm.pc
Subject: Re: NMI is SUPPOSED to be disabled!
Keywords: Memory,errors,parity,NMI
Message-ID: <10222@bigtex.cactus.org>
Date: 4 Nov 88 12:57:29 GMT
References: <549@gt-eedsp.UUCP> <10045@bigtex.cactus.org> <7465@nsc.nsc.com> <10175@bigtex.cactus.org> <12520@steinmetz.ge.com>
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Organization: Institute of Applied Cosmology, Austin TX
Lines: 35

In <12520@steinmetz.ge.com>, davidsen@crdos1.UUCP (bill davidsen) wrote:

> The way NMI is useful is for situations requiring panic stop of the
> current process.  [...]  There seems to be no reason for NMI on any
> recoverable condition.

Unfortunately, I've never seen Intel document anything like this.  If
Intel hadn't intended NMI to be recoverable, Intel wouldn't have
bother saving the return address, nor bothered with blocking NMI after
certain instructions (mov ss,_).

> People who regard parity as a recoverable error don't care if the
> results are valid, and I can't agree with people who talk about
> "recovering from a parity error" in any way except fixing the machine.

I doubt Intel designed NMI with parity error handling as the only
usage in mind.  Certainly debuggers must have been an intended usage.
Currently several video cards use NMI, as do many debuggers.

> A system doesn't "randomly crash" with NMI unless the hardware is
> broken or ill-designed such that it generates a panic interrupt for
> trivial conditions.

Actually, they did crash at random.  Back in the earliest days of the
PC with the earliest 8088s, before MOV SS,_ blocked interrupts, PCs
crashed somewhat randomly with applications that failed to do a CLI
before changing the stack segment.  This was *very* infrequent because
interrupts are so infrequent, and the window was only a couple of
clocks wide, but it did happen.  Anyone with hardware that used NMI in
a recoverable situation certainly would have seen spurious crashes.
It went away with later 8088s and was never an issue with the 286 or
386.
-- 
James R. Van Artsdalen      james@bigtex.cactus.org      "Live Free or Die"
Home: 512-346-2444 Work: 338-8789       9505 Arboretum Blvd Austin TX 78759