From owner-freebsd-current  Tue Sep 17 19:22:29 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA18287
          for current-outgoing; Tue, 17 Sep 1996 19:22:29 -0700 (PDT)
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA18262
          for <current@FreeBSD.org>; Tue, 17 Sep 1996 19:22:25 -0700 (PDT)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id TAA09684; Tue, 17 Sep 1996 19:22:06 -0700 (PDT)
Date: Tue, 17 Sep 1996 19:22:06 -0700 (PDT)
Message-Id: <199609180222.TAA09684@silvia.HIP.Berkeley.EDU>
To: rgrimes@GndRsh.aac.dev.com
CC: current@FreeBSD.org
In-reply-to: <199609180215.TAA01319@GndRsh.aac.dev.com> (rgrimes@GndRsh.aac.dev.com)
Subject: Re: RAM parity error
From: asami@FreeBSD.org (Satoshi Asami)
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

 * If you have ``logic parity'' instead of true parity you have defeated
 * 75 % of the purpose of even having parity on memory.  

75%?  I thought that was 100% ;)  (Ok, maybe it can check the memory
bus failure, but how often would that happen?)

 * 							 I would highly
 * encorage you to try a swapout with some ``real parity'' memory and
 * more than likely watch your problem go away...

I'd never buy a "logic parity" board myself, but unfortunately, these
machines are donated to our project (they aren't even supposed to be
running FreeBSD!) so I can't change anything in them. :(

So, do you think this is a memory problem?  Is there some other test I
can run, other than stressing the SCSI system?  (It doesn't crash when
I run the "fast bcopy" benchmark, and I think that thing stresses the
memory system a lot....)

Satoshi