From owner-freebsd-hardware  Mon Apr  1 23:16:59 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA15556
          for hardware-outgoing; Mon, 1 Apr 1996 23:16:59 -0800 (PST)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA15547
          for <freebsd-hardware@FreeBSD.org>; Mon, 1 Apr 1996 23:16:55 -0800 (PST)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA03313; Mon, 1 Apr 1996 23:15:00 -0800
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199604020715.XAA03313@GndRsh.aac.dev.com>
Subject: Re: Parity Errors
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Mon, 1 Apr 1996 23:15:00 -0800 (PST)
Cc: cschuber@orca.gov.bc.ca, freebsd-hardware@FreeBSD.org
In-Reply-To: <199604020145.LAA08833@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 2, 96 11:15:29 am"
X-Mailer: ELM [version 2.4ME+ PL11 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hardware@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> Cy Schubert - ITSD Open Systems Group stands accused of saying:
> 
> > 4.x, and Linux (1.1, 1.2, and 1.3) without any parity errors.  The
> > QA Plus diagnostic package, which I've used to find many parity
> > errors before, e.g. when purchasing memory upgrades, did not
> > complain about any problems. 
> 
> Diagnotics like QAPlus aren't worth spit.  They don't exercise memory
> in any of the dozens of interesting ways that 'real' operating systems
> do.

And they can't test memory like a real memory tester either.  I can
show you sticks of simms that run QAPlus for weeks on end but fail
under FreeBSD and fail in a simm tester.

...
> > I can configure the machine for memory and/or cache read or write
> > wait states independently.  Should I add a wait state and where,
> > memory or cache, read or write?
> 
> If you can disable parity checking with your BIOS, do that.

DO NOT DO THIS!   Ignoring a hardware fault indicated by the motherboard
logic is asking for more problems that it will ever solve.  This _CAN_
lead to SERIOUS file system corruption!

> Failing that,
> wind your main memory read and write waitstates out as slow as they'll go,
> and if you can add DMA waitstates then do that too.

Wind them out 1 step at a time, going overboard can cause more problems
than it solves.  Start with the BIOS setup defaults, if you have tweaked
these down to zero from a default of 1 it is most likely the cause of
your problem.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD