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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.