From: devzero@web.de
To: Lee Revell <rlrevell@joe-job.com>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org, pavel@ucw.cz
Subject: Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)
Date: Tue, 06 Mar 2007 18:54:13 +0100 [thread overview]
Message-ID: <1667859354@web.de> (raw)
>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)
regards
roland
> -----Ursprüngliche Nachricht-----
> Von: "Lee Revell" <rlrevell@joe-job.com>
> Gesendet: 06.03.07 18:29:58
> An: "devzero@web.de" <devzero@web.de>
> CC: linux-kernel@vger.kernel.org, greg@kroah.com, pavel@suse.cz
> Betreff: Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)
> On 3/4/07, devzero@web.de <devzero@web.de> wrote:
> > It seems, that BadRAM is not being maintained very actively and the original author doesn`t seem to have the time pushing it into mainline, but i know it's actively being used by more then just a handful of people. Unfortunately there is no mailinglist to approve this and some "central point of communication" besides Rick van Rein doesn't seem to exist. There is a fork named BadMEM at http://sourceforge.net/projects/badmem, Memtest86 also supporting BadRAM and i have seen LOTs of discussion about BadRAM on the net. Most of that discussion was due to problems getting it run with Kernel XYZ.
> >
> > Basically, this feature is a matter of adding/modifying 200 lines of code, so im even more wondering, why it exists for more than 7 years and nothing happening here.
>
> Because most kernel developers don't have time to scour the net for
> random kernel patches and pull them. If you have a useful patch you
> want merged it's up to you to push it.
>
> What's so hard about submitting a 200 line patch to LKML?
>
> Lee
>
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
next reply other threads:[~2007-03-06 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 17:54 devzero [this message]
2007-03-07 9:03 ` [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!) Pavel Machek
-- 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=1667859354@web.de \
--to=devzero@web.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--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.