Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!amdahl!bnrmtv!connery
From: connery@bnrmtv.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Code to perform warm reboot.
Message-ID: <1474@bnrmtv.UUCP>
Date: Fri, 27-Feb-87 11:14:44 EST
Article-I.D.: bnrmtv.1474
Posted: Fri Feb 27 11:14:44 1987
Date-Received: Sun, 1-Mar-87 14:51:04 EST
References: <3258@j.cc.purdue.edu> <415@omepd> <10075@cgl.ucsf.edu.ucsfcgl.UUCP> <850@mtunb.UUCP>
Organization: Bell Northern Research, Mtn. View, CA
Lines: 38

> In article <10075@cgl.ucsf.edu.ucsfcgl.UUCP> kneller@socrates.ucsf.edu.UUCP (PUT YOUR NAME HERE) writes:
> >>>The following is Macro code to make an IBM PC and true compatibles
> >>>perform a warm reboot.
> >>> [...showing a simple assembler program to jump to F000:FFF0...]
> >>
> Etc.

Okay, so I've got a REBOOT.COM file that performs a warm boot on my IBM
PC-AT just fine.  And I've got a debugger board of one type or another
(mine happens to be a periscope) with a breakout switch.  Now when I'm
not using the debugger, the breakout switch generates an NMI which causes
a PARITY CHECK 2 message to appear on the screen.  That's because parity
checks also use the NMI interrupt.

Now lets say I'd like to write a little resident program that traps NMI.
Ignoring for the moment that it should also determine whether the NMI is
a real parity error or not, it will perform a reboot when I press my
breakout switch.  Its easy enough to put such a program together and it
works just fine, except that the reset isn't total enough.  The machine
starts to reboot, and then bombs out with a PARITY CHECK 2 shortly after
the RAM test completes.  It would appear that the minute the processor
enables interrupts (or perhaps checks some status word in memory) it
notices that there is still a parity error pending.

Now this program works just fine on an IBM PC, PC/XT and an AT clone, but
not on my PC-AT.  I've tried a couple of obvious things, like issuing an
EOI, resetting various locations in the BIOS data area, tracing through
the reboot code in the Tech. Ref. and got no where.  The latter course
would presumably solve the problem eventually, but I'm not sure its worth
the effort.

So anyway, does someone have a clue what is wrong here?

Glenn
-- 

Glenn Connery, Bell Northern Research, Mountain View, CA
{hplabs,amdahl,3comvax}!bnrmtv!connery