Date: Mon, 18 Aug 1997 23:12:30 -0700 (PDT) From: asami@cs.berkeley.edu (Satoshi Asami) To: ken@plutotech.com Cc: hardware@FreeBSD.ORG Subject: Re: parity errors Message-ID: <199708190612.XAA27378@silvia.HIP.Berkeley.EDU> In-Reply-To: <199708190537.XAA11729@pluto.plutotech.com> (message from Kenneth Merry on Mon, 18 Aug 1997 23:37:07 -0600 (MDT))
next in thread | previous in thread | raw e-mail | index | archive | help
* I agree, you should see some sort of error. I had some ram trouble * on one of my machines (ASUS P/I-XP6NP5 MB), and I got a message that * specifically said "ram parity error". It must have been from * /sys/i386/isa/intr_machdep.c. (I grepped for "parity error") Oh, I see. (That code is in "isa/isa.c" in 2.2, by the way.) * I'm not so sure you'd get any NMI messages unless you have * parity checking turned on. If that doesn't work, try turning on ECC * support. ECC is error correction, so the motherboard will interrupt only if it's not correctable (two bits of error?). That is why I'm testing stuff now with parity on. * I would put the SIMMs in the machine two at a time and swap them * around until you isolate the bad SIMMs. Of course that'll take a while, I * imagine, with a make world test. One test that I used that worked * sometimes was to crank up a ton of xv processes with big pictures -- enough * to eat up all the ram and some of the swap. That usually had the effect * of crashing the machine with a "RAM parity error". Of course you'd want to * display the xv processes on a remote machine so you catch the panic * message. Thanks for the advice, I opened up some more xv's and now the system is finally swapping. The make world is still running happily, though. Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708190612.XAA27378>