Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!decvax!ima!johnl
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Phoenix BIOS and NMI problem
Message-ID: <657@ima.ISC.COM>
Date: Sun, 16-Aug-87 19:26:50 EDT
Article-I.D.: ima.657
Posted: Sun Aug 16 19:26:50 1987
Date-Received: Mon, 17-Aug-87 00:39:11 EDT
References: <1342@killer.UUCP>
Reply-To: johnl@ima.UUCP (John R. Levine)
Organization: Not enough to make any difference
Lines: 24
Keywords: Phoenix BBIOS
Summary: it usually means you have bad RAM

In article <1342@killer.UUCP> robertl@killer.UUCP (Robert Lord) writes:
>Also:  When compiling a program in Turbo C, I sometimes get an NMI error,
>and it asks: (S)hut off NMI, (R)eboot, or any key to continue.  
>I have been told that this is a non maskable interrupt because the processor
>is going too fast for the compiler.  This would make sense, because whenever
>I get the error it seems like part of my progam is missing (but it compiles
>fine).  Any ideas?

Somebody is pulling your leg. Compilers don't care how fast processors go,
just whether they work or not. On PCs, the usual reason that you get an NMI
interrupt is that a byte was fetched from memory and its parity was wrong.
That usually means that one of your memory chips is going bad. IBM PCs and XTs
attempt to locate the bad chip and to print out an obscure number that tells
which chip is bad. If your BIOS doesn't do that, try running whatever
diagnostics came with the computer and tell them to test your memory.

Another, less likely possibility is that there is a bug in Turbo that
jumps to the NMI code in the BIOS.  I say it's less likely because none of
the Turbo bugs I've seen discussed resemble that.
-- 
John R. Levine, Cambridge MA, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
The Iran-Contra affair:  None of this would have happened if Ronald Reagan
were still alive.