Loading...

coyotos-dev@coyotos.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [coyotos-dev] Scheduler design Valerio Bellizzomi Sun Aug 13 17:00:55 2006

On 26/03/2006, at 21.47, Jonathan Adams wrote:

>On 3/26/06, Valerio Bellizzomi <[EMAIL PROTECTED]> wrote:
>> On 26/03/2006, at 12.44, Jonathan S. Shapiro wrote:
>> >But step back: I don't really understand the motivation for IMT. Memory
>> >doesn't go bad at random. It either goes bad physically, which can be
>> >tested at install time, or it goes bad due to partical hits. The latter
>> >can be solved by ECC, and can't be conclusively solved by anything
less.
>>
>> We have bad class C memory that fails often, ECC masks the error, it
does
>> not eliminate it.
>> Sooner or later the chip degenerates and ECC can't help anymore. It is
>> safer to change the faulty bank asap.
>
>So why don't you watch for ECC corrections, and when the error rate
>exceeds a threshold, flag the DIMM as "needs replacement"?  That, plus
>a memory "scrubber" to make sure errors are corrected before they get
>uncorrectable, would seem like a better trade-off.
>
>(Of course, you have to be able to get an Correctable Error interrupt
>to be able to do this...)
>
>Cheers,
>- jonathan

ECC has to be enabled in the BIOS, we would need a method to detect when
ECC is disabled.
It would be simpler to implement, I considered LinuxECC before, but most of
the time we work with cheap non-ECC RAM.

val


_______________________________________________
coyotos-dev mailing list
[EMAIL PROTECTED]
http://www.coyotos.org/mailman/listinfo/coyotos-dev