From owner-freebsd-stable Mon Jun 29 15:41:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25576 for freebsd-stable-outgoing; Mon, 29 Jun 1998 15:41:41 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from homer.supersex.com (homer.supersex.com [209.5.1.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25556 for ; Mon, 29 Jun 1998 15:41:31 -0700 (PDT) (envelope-from leo@homer.supersex.com) Received: (from leo@localhost) by homer.supersex.com (8.8.8/8.8.5) id SAA18881; Mon, 29 Jun 1998 18:42:21 -0400 (EDT) Message-ID: <19980629184220.15472@supersex.com> Date: Mon, 29 Jun 1998 18:42:20 -0400 From: Leo Papandreou To: stable@FreeBSD.ORG Subject: Re: determining ecc errors on freebsd-stable References: <199806290401.OAA02134@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Tom on Mon, Jun 29, 1998 at 08:42:31AM -0700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 08:42:31AM -0700, Tom wrote: > [...] > > Summary: > > - ECC is MUCH better than non-ECC Will ECC on the cache trap RAM errors even if the RAM doesnt have ECC? > - Memory failure is rare. FreeBSD still doesn't have multi-path IO to > recover from controler card failure, which occurs much more often. Or, > clustering which can protect against software failures (which are still > much common than any kind of hardware failure). So putting so much > emphasis on ECC is unnecessary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message