From owner-freebsd-hackers Sat Oct 25 13:59:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23218 for hackers-outgoing; Sat, 25 Oct 1997 13:59:10 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA23206 for ; Sat, 25 Oct 1997 13:59:06 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xPDH4-0006F2-00; Sat, 25 Oct 1997 13:57:35 -0700 Date: Sat, 25 Oct 1997 13:57:34 -0700 (PDT) From: Tom To: freebsd-hackers@freebsd.org Subject: Re: Parity Ram In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote: > Can someone fill me in on when you would want to use parity ram as opposed Why? To discover memory problems before they corrupt data, and cause random panics, core dumps, hangs, or file system corruption. Personally, I use ECC capable motherboards that can actually use parity to fix some errors. > to non-parity ram these days? If there was some anomaly in memory how > would freebsd handle it (is there a trap for parity error?) These days? RAM can fail. Nothing has changed in the last 10 years. I've bought about a gig of RAM in the last couple of months, a good percentage of SIMMs still arrive DOA. FreeBSD systems simple reboot upon parity errors. This is pretty safe thing to do. Much better than what a non-parity system would at this point (ex. corrupt your filesystems). A smarter thing to do, might be to simple stop the process owning the memory that failed, and flag the area as unusable (NT does this). Doesn't help much if kernel is in the bad memory area though. Tom