beckman@iuvax.cs.indiana.edu (Peter Beckman) (11/21/90)
Memory parity interrupt at 0BC6:006D type (S)hut NMI (R)eboot, other keys to continue I have a 386/33, Phoenix Bios, 4 Meg in SIMMS, and since I rebooted, I can't recreate it. What should I do? -Pete
grege@gold.gvg.tek.com (Greg Ebert) (11/21/90)
In article <73334@iuvax.cs.indiana.edu> beckman@iuvax.cs.indiana.edu (Peter Beckman) writes: >Memory parity interrupt at >0BC6:006D >type (S)hut NMI (R)eboot, other keys to continue > >I have a 386/33, Phoenix Bios, 4 Meg in SIMMS, and since I rebooted, I >can't recreate it. What should I do? > If your BIOS auto-sizes RAM (as most do), start popping-out SIMMS until the error goes away. Now you've located the bad SIMM. Take it to work/school and ''exchange it'' [just kidding]. Be aware that you will need to move them around to get contiguous RAM. This trick *WONT* work if your system uses 1Mx9 SIMMS; I suspect your system uses the 256Kx36 format so you probably don't need to worry. Also, try the (S)hut option. Sounds like it will silence future parity errors so you can boot and run stuff < 1M.
swh@hpcupt1.cup.hp.com (Steve Harrold) (11/21/90)
>>> Memory parity interrupt at >>> 0BC6:006D >>> type (S)hut NMI (R)eboot, other keys to continue >>> >>> I have a 386/33, Phoenix Bios, 4 Meg in SIMMS, and since I rebooted, I >>> can't recreate it. What should I do? ---------- You may be experiencing a false alarm here. My HP Vectra ES/12 (a 286 with extended memory) periodically (once every few months) issues this message. The work-around is to power off/on and it goes away. Perhaps this is truly an intermittent hardware problem, but I think, in my case, it is software related. After discussions with other people who have also experienced this behaviour, I've concluded that some memory managers do not do a good job of resetting memory at reboot. Aborting Windows, or Ventura Publisher, often seems to be trigger the problem. Next time you hit this condition, think back and check if, since the last power on, you aborted an application or OS extension that was exercising or controlling extended memory. If so, you may be experiencing what I've been seeing, and you can blame the software. (Now, try and get THAT fixed :-)
poffen@sj.ate.slb.com (Russ Poffenberger) (11/22/90)
In article <73334@iuvax.cs.indiana.edu> beckman@iuvax.cs.indiana.edu (Peter Beckman) writes: >Memory parity interrupt at >0BC6:006D >type (S)hut NMI (R)eboot, other keys to continue > >I have a 386/33, Phoenix Bios, 4 Meg in SIMMS, and since I rebooted, I >can't recreate it. What should I do? > Nothing unless it starts happening again with more regularity. Believe it or not, but DRAMs have a specified soft error rate. It is usually one bit in error every godawful long time. Things like nuclear particles and cosmic rays can cause a bit to flip, causing a once in a blue moon parity error. I wouldn't worry unless it starts becoming chronic, and at the same address, then suspect a particular chip/SIMM. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
shite@unf7.UUCP (Stephen Hite) (12/02/90)
In article <56470002@hpcupt1.cup.hp.com>, swh@hpcupt1.cup.hp.com (Steve Harrold) writes: > >>> Memory parity interrupt at > >>> 0BC6:006D > >>> type (S)hut NMI (R)eboot, other keys to continue > >>> > few months) issues this message. The work-around is to power off/on and > it goes away. Perhaps this is truly an intermittent hardware problem, > but I think, in my case, it is software related. > This sounds like a good idea. It happened to be also. In my case, it was pretty obvious what the problem was. I took out 4 of the 8 meg I had installed in my 386 PC and when I put it back in, some of the chips were not as well seated as I had thought. I reseated the chips and my problem has vanished. ----------------------------- Steve Hite ...gatech!uflorida!unf7!shite shite@sinkhole.unf.edu