From owner-freebsd-hardware  Mon Aug 18 23:13:16 1997
Return-Path: <owner-freebsd-hardware>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA13998
          for hardware-outgoing; Mon, 18 Aug 1997 23:13:16 -0700 (PDT)
Received: from silvia.HIP.Berkeley.EDU (wck-ca8-25.ix.netcom.com [204.31.231.89])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13993
          for <hardware@FreeBSD.ORG>; Mon, 18 Aug 1997 23:13:12 -0700 (PDT)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.6/8.6.9) id XAA27378; Mon, 18 Aug 1997 23:12:30 -0700 (PDT)
Date: Mon, 18 Aug 1997 23:12:30 -0700 (PDT)
Message-Id: <199708190612.XAA27378@silvia.HIP.Berkeley.EDU>
To: ken@plutotech.com
CC: hardware@FreeBSD.ORG
In-reply-to: <199708190537.XAA11729@pluto.plutotech.com> (message from Kenneth Merry on Mon, 18 Aug 1997 23:37:07 -0600 (MDT))
Subject: Re: parity errors
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-freebsd-hardware@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

 * 	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