From owner-freebsd-stable@FreeBSD.ORG Tue Jun 27 00:06:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8E6316AA52 for ; Tue, 27 Jun 2006 00:06:37 +0000 (UTC) (envelope-from webmaster@hirsch.it) Received: from server1.hirsch.it (server1.hirsch.it [213.239.214.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A9043D8C for ; Mon, 26 Jun 2006 23:38:41 +0000 (GMT) (envelope-from webmaster@hirsch.it) Received: from hsi-kbw-085-216-025-126.hsi.kabelbw.de ([85.216.25.126] helo=[192.168.101.121]) by server1.hirsch.it with esmtpa (Exim 4.50) id 1Fv0f6-00088i-5K; Tue, 27 Jun 2006 01:38:40 +0200 Message-ID: <44A06FFB.40104@hirsch.it> Date: Tue, 27 Jun 2006 01:38:35 +0200 From: "M.Hirsch" User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> <20060626235355.Q95667@atlantis.atlantis.dp.ua> <44A04FD2.1030001@hirsch.it> <20060627011512.N95667@atlantis.atlantis.dp.ua> <44A06233.1090704@hirsch.it> <20060627014335.E87535@atlantis.atlantis.dp.ua> <44A068A7.3090403@hirsch.it> <20060627020819.L3403@atlantis.atlantis.dp.ua> In-Reply-To: <20060627020819.L3403@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "server1.hirsch.it", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Yes, the result may be correct. 'Do not take "ECC" for "equals additional security"' So I understand what's ECC good for, other than the usual "marketing talk". But, in FreeBSD, the function is a result of hardware-level correction. Something that only kicks in in _real_ _serious_ situations. I just would like you (not specifically you, Dmitry) to aknowledge that broken RAM is worth a "panic" in "standard situations"- if I may call it like that. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 00:06:38 -0000 Yes, the result may be correct. 'Do not take "ECC" for "equals additional security"' So I understand what's ECC good for, other than the usual "marketing talk". But, in FreeBSD, the function is a result of hardware-level correction. Something that only kicks in in _real_ _serious_ situations. I just would like you (not specifically you, Dmitry) to aknowledge that broken RAM is worth a "panic" in "standard situations"- if I may call it like that. If the RAM is broken for some bits, chances are great that there are more following soon. ... from the replies I got via PM, I feel some people don't agree with that.... Sticks don't just break on a single bit. From my experience, a stick that's got any problems at all, will cause even more trouble soon... If a hardware problem isn't worth panick'ing, what else is? (don't answer this one please, this was a rhetorical question - to those who didn't get it...) Still, I'd rather have the node break down completely than that... M.^