[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110623104903.GA14754@phantom.vanrein.org>
Date: Thu, 23 Jun 2011 10:49:03 +0000
From: Rick van Rein <rick@...rein.org>
To: Rick van Rein <rick@...rein.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Stefan Assmann <sassmann@...nic.de>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
tony.luck@...el.com, andi@...stfloor.org, mingo@...e.hu,
rdunlap@...otime.net, Nancy Yuen <yuenn@...gle.com>,
Michael Ditto <mditto@...gle.com>
Subject: Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)
Hello,
My last email may have assumed that you knew all about BadRAM; this
is probably worth an expansion:
> If you plug 10 DIMMs into your machine, and each has a faulty row
> somewhere, then you will get into trouble if you stick to 5 patterns.
With "trouble" I mean that a 6th pattern would be merged with the
nearest of the already-found 5 patterns. It may be that this leads
to a pattern that covers more addresses than strictly needed. This
is how I can guarantee that there are never more than 5 patterns,
and so never more than the cmdline can take. No cut-offs are made.
> But if you happen to run into a faulty DIMM from time to time, the
> patterns should be your way out.
...without needing to be more general than really required. Of course,
if all your PCs ran on 10 DIMMs, you could expand the number of
patterns to a comfortably higher number, but what I've seen with the
various cases I've supported, this has never been necessary.
> > that would mean running in a known-bad configuration,
> > and even a hard crash would be better.
>
> ...which is so sensible that it was of course taken into account in
> the BadRAM design!
Meaning, that is why patterns are merged if the exceed the rather high
number of 5 patterns. Rather waste those extra pages than running
into a known fault.
This high number of patterns is not at all common, however, making it
safe to assume that the figure is high enough, in spite of leaving
space on even LILO's cmdline to support adding several other tweaks.
-Rick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists