From owner-freebsd-current  Tue Sep 17 21:03:05 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA24921
          for current-outgoing; Tue, 17 Sep 1996 21:03:05 -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 VAA24892
          for <current@FreeBSD.org>; Tue, 17 Sep 1996 21:03:01 -0700 (PDT)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id VAA09813; Tue, 17 Sep 1996 21:01:15 -0700 (PDT)
Date: Tue, 17 Sep 1996 21:01:15 -0700 (PDT)
Message-Id: <199609180401.VAA09813@silvia.HIP.Berkeley.EDU>
To: dg@root.com
CC: current@FreeBSD.org, haertel@ichips.intel.com, erich@uruk.org
In-reply-to: <199609180316.UAA11084@root.com> (message from David Greenman on Tue, 17 Sep 1996 20:16:07 -0700)
Subject: Re: RAM parity error
From: asami@FreeBSD.org (Satoshi Asami)
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

 *    I'll bet that the real traceback has a "#4.5" that is ahc_scsi_cmd(). gdb
 * often doesn't decode the traceback correctly since it doesn't deal with
 * trapframes correctly. I'm seeing *exactly* the same behavior on wcarchive (B0
 * Orion, Stepping 1 of the P6). During heavy disk I/O, I occasionally see "RAM
 * parity errors" during the outsl instruction.

That's very interesting to hear.  This machine is running 2.2-current
(about 1 day old), btw.  Intel Natoma, step unknown.

By the way, I just remembered that it once crashed during a newfs
(over a 35-disk ccd) too.  A single disk iozone won't crash it, so I
guess having the load of multiple disk I/O's is the problem.

Satoshi