From: Pavel Machek <pavel@ucw.cz>
To: devzero@web.de
Cc: Lee Revell <rlrevell@joe-job.com>,
greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)
Date: Wed, 7 Mar 2007 10:03:11 +0100 [thread overview]
Message-ID: <20070307090311.GA4285@elf.ucw.cz> (raw)
In-Reply-To: <1667859354@web.de>
Hi!
> >What's so hard about submitting a 200 line patch to LKML?
>
> that's what i was wondering about ;D
> it's not the first time, that i see nice features not being submitted to lkml.
>
> anyway - pavel (thanks btw!) just pointed me to some param "mem=exactmap" :
>
> >I think functionality is there in latest vanila with mem=exactmap even
> >w/o patches.
>
> so, maybe we need to find out _if_ and _how_ this could make BadRAM obsolete (i.e. if this is a good alternative) ?
> (so we won't need to discuss about BadRAM inclusion anymore. :)
>
> what i found is:
>
> 894 memmap=exactmap [KNL,IA-32,X86_64] Enable setting of an exact
> 895 E820 memory map, as specified by the user.
> 896 Such memmap=exactmap lines can be constructed based on
> 897 BIOS output or other requirements. See the memmap=nn@ss
> 898 option description.
> 899
> 900 memmap=nn[KMG]@ss[KMG]
> 901 [KNL] Force usage of a specific region of memory
> 902 Region of memory to be used, from ss to ss+nn.
> 903
> 904 memmap=nn[KMG]#ss[KMG]
> 905 [KNL,ACPI] Mark specific memory as ACPI data.
> 906 Region of memory to be used, from ss to ss+nn.
> 907
> 908 memmap=nn[KMG]$ss[KMG]
> 909 [KNL,ACPI] Mark specific memory as reserved.
> 910 Region of memory to be used, from ss to ss+nn.
> this indeed looks like something being able to replace BadRAM, but
> the question is, how to handle/enable that and how to translate
> BadRAM patterns from memtest86 to be usable. (i.e.: writing a HowTo
> for the average user not being a kernel wizard)
Writing a howto, or maybe writting a shellscript to do a translation
:-). It will not be trivial, but certainly better than trying to push
the badram patch. Good luck ;-).
(e820 map is available from dmesg after boot, and perhaps from other
places. First, you'll need to duplicate it on cmdline using
memmap=... arguments. Then, if bad ram is in the middle of something,
you'll need to split memmap= accordingly).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2007-03-07 9:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 17:54 [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!) devzero
2007-03-07 9:03 ` Pavel Machek [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-06 18:02 devzero
2007-03-04 19:13 devzero
[not found] ` <f24d23310703041204r2e729cc4ke93a9cbb70ef2e85@mail.gmail.com>
2007-03-04 20:06 ` debian developer
2007-03-06 17:12 ` Bill Davidsen
2007-03-06 17:23 ` Lee Revell
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=20070307090311.GA4285@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=devzero@web.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.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