From: Rick van Rein <rick@vanrein.org>
To: Rick van Rein <rick@vanrein.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Stefan Assmann <sassmann@kpanic.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, tony.luck@intel.com,
andi@firstfloor.org, mingo@elte.hu, rdunlap@xenotime.net,
Nancy Yuen <yuenn@google.com>, Michael Ditto <mditto@google.com>
Subject: Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)
Date: Thu, 23 Jun 2011 10:49:03 +0000 [thread overview]
Message-ID: <20110623104903.GA14754@phantom.vanrein.org> (raw)
In-Reply-To: <20110623103320.GB2910@phantom.vanrein.org>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-06-23 10:49 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-22 11:18 [PATCH v2 0/3] support for broken memory modules (BadRAM) Stefan Assmann
2011-06-22 11:18 ` [PATCH v2 1/3] Add string parsing function get_next_ulong Stefan Assmann
2011-06-22 11:18 ` [PATCH v2 2/3] support for broken memory modules (BadRAM) Stefan Assmann
2011-06-22 11:18 ` [PATCH v2 3/3] Add documentation and credits for BadRAM Stefan Assmann
2011-06-22 18:00 ` [PATCH v2 0/3] support for broken memory modules (BadRAM) Andrew Morton
2011-06-22 18:06 ` Josh Boyer
2011-06-22 18:09 ` Randy Dunlap
2011-06-22 18:11 ` Nancy Yuen
2011-06-22 18:13 ` H. Peter Anvin
2011-06-22 19:01 ` Nancy Yuen
2011-06-22 19:06 ` H. Peter Anvin
2011-06-22 18:24 ` Andi Kleen
2011-06-22 18:38 ` Andrew Morton
2011-06-22 18:56 ` Andi Kleen
2011-06-22 19:05 ` H. Peter Anvin
2011-06-22 19:15 ` Andi Kleen
2011-06-22 20:25 ` H. Peter Anvin
2011-06-22 20:28 ` Andi Kleen
2011-06-22 19:46 ` [PATCH] x86: e820: Eliminate bubble sort from sanitize_e820_map Mike Ditto
2011-06-22 20:18 ` [PATCH v2 0/3] support for broken memory modules (BadRAM) Stefan Assmann
2011-06-23 10:33 ` Rick van Rein
2011-06-23 10:49 ` Rick van Rein [this message]
2011-06-23 10:10 ` Rick van Rein
2011-06-22 18:15 ` H. Peter Anvin
2011-06-22 20:30 ` Stefan Assmann
2011-06-22 20:33 ` H. Peter Anvin
2011-06-23 13:39 ` Matthew Garrett
2011-06-23 14:08 ` Stefan Assmann
2011-06-23 14:12 ` Matthew Garrett
2011-06-23 15:37 ` Stefan Assmann
2011-06-23 16:30 ` H. Peter Anvin
2011-06-24 0:59 ` Andi Kleen
2011-06-23 17:00 ` Andi Kleen
2011-06-23 17:12 ` Luck, Tony
2011-06-24 1:03 ` Craig Bergstrom
2011-06-24 1:08 ` Andi Kleen
2011-06-24 1:22 ` Craig Bergstrom
2011-06-24 8:05 ` Rick van Rein
2011-06-24 14:34 ` Craig Bergstrom
2011-06-24 16:16 ` H. Peter Anvin
2011-06-24 16:40 ` Luck, Tony
2011-06-24 16:56 ` Rick van Rein
2011-06-24 17:14 ` H. Peter Anvin
[not found] <fa.fHPNPTsllvyE/7DxrKwiwgVbVww@ifi.uio.no>
2011-06-24 21:10 ` Shane Nay
2011-06-28 2:33 ` Craig Bergstrom
2011-06-29 8:08 ` Rick van Rein
2011-06-29 15:28 ` craig lkml
2011-06-29 16:06 ` Craig Bergstrom
2011-06-29 21:24 ` Tony Luck
2011-06-30 14:32 ` Jody Belka
-- strict thread matches above, loose matches on Subject: below --
2011-06-21 9:23 Stefan Assmann
2011-06-21 22:02 ` Andrew Morton
2011-06-22 11:11 ` Stefan Assmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110623104903.GA14754@phantom.vanrein.org \
--to=rick@vanrein.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mditto@google.com \
--cc=mingo@elte.hu \
--cc=rdunlap@xenotime.net \
--cc=sassmann@kpanic.de \
--cc=tony.luck@intel.com \
--cc=yuenn@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).