From owner-freebsd-current Fri Jan 15 14:27:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24205 for freebsd-current-outgoing; Fri, 15 Jan 1999 14:27:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24182 for ; Fri, 15 Jan 1999 14:27:14 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40330>; Sat, 16 Jan 1999 09:26:24 +1100 Date: Sat, 16 Jan 1999 09:27:01 +1100 From: Peter Jeremy Subject: Re: Weird file corruption? To: freebsd-current@FreeBSD.ORG Message-Id: <99Jan16.092624est.40330@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Zach Heilig wrote: >Except simm checkers don't always catch errors, so if the simm passes, >there still is no guarantee (but simm checkers do weed out obvious >duds quicker than trying in a system). Unfortunately, there is no >conclusive test [that I know about] to prove a simm is "good". I'd agree with that. The guts of a DRAM (or any type) is high-speed analog circuitry with delicate multi-phase clocking (the external clocks and selects are internally subdivided into maybe 20 phases). There can be pattern-sensitive crosstalk between rows or columns that depends on inter-access timings - or even how long since a particular row was refreshed. I suspect it's impossible to prove that a SIMM is good - there are two many combinations to test. >Even better is to only use motherboards that support parity and/or ECC, >with parity/ecc simms/dimms. This is the only practical way to detect memory problems. A subsidiary problem is that, unlike say Solaris, FreeBSD doesn't automatically report ECC errors. Without this, your memory controller can be furiously correcting a hard single-bit error and die when it glitches to a double-bit error. Someone did post a script that checked and cleared the relevant register in an i440 several months ago, but I seem to have mislaid both the script and reference :-(. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message