Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jun 2006 02:21:28 +0300 (EEST)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        "M.Hirsch" <webmaster@hirsch.it>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Message-ID:  <20060627020819.L3403@atlantis.atlantis.dp.ua>
In-Reply-To: <44A068A7.3090403@hirsch.it>
References:  <E1FuYsL-000HT3-H2@dilbert.firstcallgroup.co.uk> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jun 2006, M.Hirsch wrote:
>> If you're using hardware w/o ECC, it just can't tell whether error present
>> or absent. So ECC _is_ the way to detect (not mask) broken hardware.
>> 
> Ok, thanks. I think I understand the meaning of ECC now.
> So, unlike my supplier claims, ECC is not supposed to help against hardware 
> failures.
> But it is the way to detect them, right?

  ECC stands for Error Checking and Correction. It's a hardware feature,
and its primary task is Checking (that is, detection) of errors. It just 
happens that number of additional bits which carry checking code is sufficient 
to correct _any_ _single-bit_ data error (not mask it, but really correct), 
and to detect any double-bit and most of several-bit errors (w/o 
correction).

>> Intel's ECC-capable chipset allows it. But if we're speaking about
>> production environment, such behaviour (abnormal termination on _corrected_
>> error) is unacceptable.
>
> "abnormal termination" is not only acceptable for me, it is what I am looking 
> for.
> Make the node crash completely, so one of the others can take over its 
> task(s).

  Again, when single-bit correction has happened, it's not fake, the result is 
actually correct. Why panic the machine immediately if all data OK?

Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060627020819.L3403>