Re: [BLUG] New OS

I must apologize, but I feel that it may be a bad assumption to assume
that just because the problem sounds difficult that it hasn't been done.

Simón may not remember clearly, but at the time he was saying that
there was a single line in the kernel logs that made a reference to the
bad RAM.

Such a task doesn't even seem all that complex in theory. Presumably
Simón was using paritied RAM, (or some other type of RAM that can
signal errors). Such RAM throws an NMI (non-maskable interrupt) when an
error is encountered. Traditional OSes panic at this point. However,
there is no reason why it has to panic. You know where the error is now,
so turn off that RAM and keep going.

The theory of operation is sound. It doesn't require RAM to be scanned
before allocation. (If you clear the RAM when you allocate it, and catch
the error then, that should be good enough for the general case.)

More importantly, it is backed up with experience which fits. Simón
knows he worked his machine hard enough he was certain it wasn't the
RAM. I know Simón told me when he looked for it, he found a note in his
kernel log.

Cheers,
Steven Black

On Mon, Sep 22, 2008 at 03:48:51PM -0400, Shei, Shing-Shong wrote:
> I am afraid that this is not a correct assumption. Different OSes has
> different way of allocating/using memory. Probably it's just lucky that
> Ubuntu had not touched the bad memory block. --SS
>
> > On Mon, Sep 22, 2008 at 3:34 PM, Shei, Shing-Shong <shei@cs.indiana.edu> wrote:
> >
> >> I am curious -- how did you that " kernel just noticed the potholes and
> >> steered around them"? --SS
> >>
> >
> > I simply mean that with that particular stick of damaged memory I ran
> > Ubuntu perfectly fine without rebooting for several weeks, and with
> > the same damaged stick Windows XP couldn't even finish installing (or
> > boot when I got it installed using other memory).
> >
> > Since it relates to how memory is used, I only assumed that it was the
> > kernels that handled the errors with aplomb or not.
> >
> > Simón
> >
> > _______________________________________________
> > BLUG mailing list
> > BLUG@linuxfan.com
> > http://mailman.cs.indiana.edu/mailman/listinfo/blug
> >
>
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug

--
Steven Black <blacks@indiana.edu> / KeyID: 8596FA8E
Fingerprint: 108C 089C EFA4 832C BF07 78C2 DE71 5433 8596 FA8E