[RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[devzero]

Hello !

There's some really nice feature-patch named BadRAM at http://rick.vanrein.org/linux/badram/index.html for years now, being announced around 2000 on this list, voted for inclusion in 2.3.99.

BadRAM let's you tell the kernel to skip certain regions of ram, so you can continue using defective modules. Some older article describing BadRAM in more detail is at http://www.linuxjournal.com/article/4489

Some may tell "better buy some new ram" , but think of scenarios where ram being soldered onboard, modules not being available anymore due to special format - or people not having the money to buy new modules. Furthermore, this is good stuff for propaganda "Linux even works on machines with broken ram - no other operating system can do that!"

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 iŽm even more wondering, why it exists for more than 7 years and nothing happening here. I don`t know of any kernel patch which is comparable to this.

This patch is real a ressource-saver - if being a standard Linux feature, it will save even more ressources: Saving user's time (because they are pulling their hair out to get this run with kernel XYZ) and also saving CPU time  (no compile orgies anymore), and thus waste of energy.

Please comment if someone sees chances of getting this (after years of existance) into mainline and also please jump in to make the good thing happen !

Historical patch collection at:
http://rick.vanrein.org/linux/badram/download.html

Most recent version of BadRAM should be:
http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch

Sorry for being a little bit "noisy" here, but I think BadRAM is a great feature and Linux could really benefit from that.

regards
Roland K.
Sysadmin


List:       linux-kernel
Subject:    Re: Free Linux Driver Development!
From:       devzero () web ! de
Date:       2007-02-04 21:37:33
Message-ID: 1605445807 () web ! de
[Download message RAW]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those "volunteers, waiting to get some real work" :)

> > OK, but why isn't your army of volunteers fixing them?

> They don't know about them, or they don't have the hardware to test?
> Seriously, let the kernel-janitor's project know about any issues you
> have and they will be glad to jump on it.  Those people are just
> chomping a the bit to do something a bit bigger than "compiler warning
> cleanups" :)

So many times i have seen good ideas brought up, kernel patches being written, posted \
to lkml, being developed outside mainline for a while and then being forgotten some \
time later due to lack of energy of some individual to get this into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m not) , \
so why not "feeding" them the right way ? Where is those public and transparent and \
moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with \
sort of a "vote for this feature"-button, so those guys have something they can pick \
up? There is so much great stuff and ideas out there where they could put their work \
onto or getting involved, it just needs to be found or sort of being "managed" a \
little bit better.

For myself, i`m waiting for so quite some things to get "one step further", but they \
are more or less tied to some single individuals, for which you just cannot send some \
"hey, what`s up with your project"-message every second day. The interest in many \
nice projects often is quite low and evolution quite slow, but not only because of \
the fact that they aren`t great, but more because of not getting widely known. It`s \
not always missing specs, it`s also some missing noise/feedback for different \
features or missing of some "driving force" to bring things forward. How should one \
developer know that somebody needs a feature if those who could probably need it \
don`t request it? Maybe just because of the fact that they even imagine that such \
feature would be possible ?

Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more than \
256 devices ? Replacement of proprietary, unstable and unelegant vmware-lopp for \
being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace \
could be some infrastructure for this, but the author seems to have other \
priorities.... dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent \
implementations, but both got stuck at some early experimental stage) 

Just my 2 cents. 

Roland K.
Sysadmin

ps:
This isn`t meant to criticise any of you kernel developers since you`re doing \
fantastic work!
_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[debian developer]

The feature is not supported most prolly cos of lack of volunteers
pushing it into mainline, or it might be deprecated(is it??).
You are right in pointing out tht this could really save some ppl lots
of trouble.
am ready to help. pls contact for further queries
>
>
>
> On 3/5/07, devzero@web.de <devzero@web.de> wrote:
> >  Hello !
> >
> > There's some really nice feature-patch named BadRAM at http://rick.vanrein.org/linux/badram/index.html for years now, being announced around 2000 on this list, voted for inclusion in  2.3.99.
> >
> > BadRAM let's you tell the kernel to skip certain regions of ram, so you can continue using defective modules. Some older article describing BadRAM in more detail is at  http://www.linuxjournal.com/article/4489
> >
> > Some may tell "better buy some new ram" , but think of scenarios where ram being soldered onboard, modules not being available anymore due to special format - or people not having the money to buy new modules. Furthermore, this is good stuff for propaganda "Linux even works on machines with broken ram - no other operating system can do that!"
> >
> > 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 iŽm even more wondering, why it exists for more than 7 years and nothing happening here. I don`t know of any kernel patch which is comparable to this.
> >
> > This patch is real a ressource-saver - if being a standard Linux feature, it will save even more ressources: Saving user's time (because they are pulling their hair out to get this run with kernel XYZ) and also saving CPU time  (no compile orgies anymore), and thus waste of energy.
> >
> > Please comment if someone sees chances of getting this (after years of existance) into mainline and also please jump in to make the good thing happen !
> >
> > Historical patch collection at:
> >  http://rick.vanrein.org/linux/badram/download.html
> >
> > Most recent version of BadRAM should be:
> > http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch
> >
> > Sorry for being a little bit "noisy" here, but I think BadRAM is a great feature and Linux could really benefit from that.
> >
> > regards
> > Roland K.
> > Sysadmin
> >
> >
> > List:       linux-kernel
> >  Subject:    Re: Free Linux Driver Development!
> > From:       devzero () web ! de
> > Date:       2007-02-04 21:37:33
> > Message-ID: 1605445807 () web ! de
> > [Download message RAW]
> >
> > First off, compliments to this announcement, I liked it very much!
> >
> > Some comment regarding those "volunteers, waiting to get some real work" :)
> >
> > > > OK, but why isn't your army of volunteers fixing them?
> >
> > > They don't know about them, or they don't have the hardware to test?
> > > Seriously, let the kernel-janitor's project know about any issues you
> > > have and they will be glad to jump on it.  Those people are just
> > > chomping a the bit to do something a bit bigger than "compiler warning
> > > cleanups" :)
> >
> > So many times i have seen good ideas brought up, kernel patches being written, posted \
> > to lkml, being developed outside mainline for a while and then being forgotten some \
> > time later due to lack of energy of some individual to get this into mainline.
> >
> > If there is an noticeably number of talented programmers (unfortunately, i`m not) , \
> > so why not "feeding" them the right way ? Where is those public and transparent and \
> > moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with \
> > sort of a "vote for this feature"-button, so those guys have something they can pick \
> > up? There is so much great stuff and ideas out there where they could put their work \
> > onto or getting involved, it just needs to be found or sort of being "managed" a \
> > little bit better.
> >
> > For myself, i`m waiting for so quite some things to get "one step further", but they \
> > are more or less tied to some single individuals, for which you just cannot send some \
> >  "hey, what`s up with your project"-message every second day. The interest in many \
> > nice projects often is quite low and evolution quite slow, but not only because of \
> > the fact that they aren`t great, but more because of not getting widely known. It`s \
> > not always missing specs, it`s also some missing noise/feedback for different \
> > features or missing of some "driving force" to bring things forward. How should one \
> > developer know that somebody needs a feature if those who could probably need it \
> > don`t request it? Maybe just because of the fact that they even imagine that such \
> > feature would be possible ?
> >
> > Where is those efforts for fixing/integrating fantastic cowloop?
> > What about badram/badmem patch ?
> > Compressed Ccaching ?
> > Somebody helping with development of dm-loop or extend loop.c to support more than \
> > 256 devices ? Replacement of proprietary, unstable and unelegant vmware-lopp for \
> > being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace \
> > could be some infrastructure for this, but the author seems to have other \
> > priorities.... dm-cow, zfs-fuse - anybody ?
> > Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent \
> > implementations, but both got stuck at some early experimental stage)
> >
> > Just my 2 cents.
> >
> > Roland K.
> > Sysadmin
> >
> > ps:
> > This isn`t meant to criticise any of you kernel developers since you`re doing \
> > fantastic work!
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> >
> > -
> >  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at   http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Bill Davidsen]

telling youdevzero@web.de wrote:
> Hello !
> 
> There's some really nice feature-patch named BadRAM at
http://rick.vanrein.org/linux/badram/index.html for years now, being
announced around 2000 on this list, voted for inclusion in 2.3.99.
> 
> BadRAM let's you tell the kernel to skip certain regions of ram, so
you can continue using defective modules. Some older article describing
BadRAM in more detail is at http://www.linuxjournal.com/article/4489

	[...snip...]
> 
> Basically, this feature is a matter of adding/modifying 200 lines of
code, so iŽm even more wondering, why it exists for more than 7 years
and nothing happening here. I don`t know of any kernel patch which is
comparable to this.
> 
Think about that... 200 lines of code which will have to be maintained 
forever, once it becomes a supported feature, for the benefit of the few 
people who can't or won't replace bad memory.

> This patch is real a ressource-saver - if being a standard Linux
feature, it will save even more ressources: Saving user's time (because
they are pulling their hair out to get this run with kernel XYZ) and
also saving CPU time (no compile orgies anymore), and thus waste of energy.
> 
Consider one technical and one human behavour issue. While memory with 
"bad spots" was common a decade ago, it's as likely with current memory 
that the memory will "throw a bad bit" once in a while, on a read or 
write anywhere in the marginal or bad chip. Depending on how the memory 
is organized that could be 1/16th of the memory as a block of 32MB on a 
512MB part, or every 16th byte in the whole memory.

As for the human issue, how many more people will use this capability to 
avoid buying memory, run with only part of the bad memory detected and 
blocked out, get unreliable operation, and think that Linux is unreliable.

> Please comment if someone sees chances of getting this (after years
> of
existance) into mainline and also please jump in to make the good thing
happen !
> 
I personally think that the patch is at best a balance between benefit 
and problems. As a patch I have to use deliberately I think it's a good 
idea. As a permanent and default part of the kernel, I'm not convinced. 
There are some patches I would love to see in mainline, like suspend2 
which includes resume as well as suspend, but this is not one of them, 
hope I've explained why.

As with so many other things in life, "it's not the cost but the upkeep."

> Historical patch collection at:
> http://rick.vanrein.org/linux/badram/download.html
> 
> Most recent version of BadRAM should be:
> http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch
> 
> Sorry for being a little bit "noisy" here, but I think BadRAM is a
great feature and Linux could really benefit from that.
> 
> regards
> Roland K.
> Sysadmin
> 
> 
> List:       linux-kernel
> Subject:    Re: Free Linux Driver Development!
> From:       devzero () web ! de
> Date:       2007-02-04 21:37:33
> Message-ID: 1605445807 () web ! de
> [Download message RAW]
> 
> First off, compliments to this announcement, I liked it very much!
> 
> Some comment regarding those "volunteers, waiting to get some real work" :)
> 
>>> OK, but why isn't your army of volunteers fixing them?
> 
>> They don't know about them, or they don't have the hardware to test?
>> Seriously, let the kernel-janitor's project know about any issues you
>> have and they will be glad to jump on it.  Those people are just
>> chomping a the bit to do something a bit bigger than "compiler warning
>> cleanups" :)
> 
> So many times i have seen good ideas brought up, kernel patches being written, posted \
> to lkml, being developed outside mainline for a while and then being forgotten some \
> time later due to lack of energy of some individual to get this into mainline.
> 
> If there is an noticeably number of talented programmers (unfortunately, i`m not) , \
> so why not "feeding" them the right way ? Where is those public and transparent and \
> moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with \
> sort of a "vote for this feature"-button, so those guys have something they can pick \
> up? There is so much great stuff and ideas out there where they could put their work \
> onto or getting involved, it just needs to be found or sort of being "managed" a \
> little bit better.
> 
> For myself, i`m waiting for so quite some things to get "one step further", but they \
> are more or less tied to some single individuals, for which you just cannot send some \
> "hey, what`s up with your project"-message every second day. The interest in many \
> nice projects often is quite low and evolution quite slow, but not only because of \
> the fact that they aren`t great, but more because of not getting widely known. It`s \
> not always missing specs, it`s also some missing noise/feedback for different \
> features or missing of some "driving force" to bring things forward. How should one \
> developer know that somebody needs a feature if those who could probably need it \
> don`t request it? Maybe just because of the fact that they even imagine that such \
> feature would be possible ?
> 
> Where is those efforts for fixing/integrating fantastic cowloop?
> What about badram/badmem patch ?
> Compressed Ccaching ?
> Somebody helping with development of dm-loop or extend loop.c to support more than \
> 256 devices ? Replacement of proprietary, unstable and unelegant vmware-lopp for \
> being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace \
> could be some infrastructure for this, but the author seems to have other \
> priorities.... dm-cow, zfs-fuse - anybody ?
> Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent \
> implementations, but both got stuck at some early experimental stage) 
> 
> Just my 2 cents. 
> 
> Roland K.
> Sysadmin
> 
> ps:
> This isn`t meant to criticise any of you kernel developers since you`re doing \
> fantastic work!
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> 


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Lee Revell]

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 iŽm 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

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[Pavel Machek]

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

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[devzero]

bill, 
i have to admit that this sounds reasonable what you tell.

maybe this patch is just something very special, having many pro's but also con's - so this also could be one reason why it exists for so long outside mainline.

regards
roland



> -----Ursprüngliche Nachricht-----
> Von: Bill Davidsen <davidsen@tmr.com>
> Gesendet: 06.03.07 18:11:34
> An: 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!)


> telling youdevzero@web.de wrote:
> > Hello !
> > 
> > There's some really nice feature-patch named BadRAM at
> http://rick.vanrein.org/linux/badram/index.html for years now, being
> announced around 2000 on this list, voted for inclusion in 2.3.99.
> > 
> > BadRAM let's you tell the kernel to skip certain regions of ram, so
> you can continue using defective modules. Some older article describing
> BadRAM in more detail is at http://www.linuxjournal.com/article/4489
> 
> 	[...snip...]
> > 
> > Basically, this feature is a matter of adding/modifying 200 lines of
> code, so iŽm even more wondering, why it exists for more than 7 years
> and nothing happening here. I don`t know of any kernel patch which is
> comparable to this.
> > 
> Think about that... 200 lines of code which will have to be maintained 
> forever, once it becomes a supported feature, for the benefit of the few 
> people who can't or won't replace bad memory.
> 
> > This patch is real a ressource-saver - if being a standard Linux
> feature, it will save even more ressources: Saving user's time (because
> they are pulling their hair out to get this run with kernel XYZ) and
> also saving CPU time (no compile orgies anymore), and thus waste of energy.
> > 
> Consider one technical and one human behavour issue. While memory with 
> "bad spots" was common a decade ago, it's as likely with current memory 
> that the memory will "throw a bad bit" once in a while, on a read or 
> write anywhere in the marginal or bad chip. Depending on how the memory 
> is organized that could be 1/16th of the memory as a block of 32MB on a 
> 512MB part, or every 16th byte in the whole memory.
> 
> As for the human issue, how many more people will use this capability to 
> avoid buying memory, run with only part of the bad memory detected and 
> blocked out, get unreliable operation, and think that Linux is unreliable.
> 
> > Please comment if someone sees chances of getting this (after years
> > of
> existance) into mainline and also please jump in to make the good thing
> happen !
> > 
> I personally think that the patch is at best a balance between benefit 
> and problems. As a patch I have to use deliberately I think it's a good 
> idea. As a permanent and default part of the kernel, I'm not convinced. 
> There are some patches I would love to see in mainline, like suspend2 
> which includes resume as well as suspend, but this is not one of them, 
> hope I've explained why.
> 
> As with so many other things in life, "it's not the cost but the upkeep."
> 
> > Historical patch collection at:
> > http://rick.vanrein.org/linux/badram/download.html
> > 
> > Most recent version of BadRAM should be:
> > http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch
> > 
> > Sorry for being a little bit "noisy" here, but I think BadRAM is a
> great feature and Linux could really benefit from that.
> > 
> > regards
> > Roland K.
> > Sysadmin
> > 
> > 
> > List:       linux-kernel
> > Subject:    Re: Free Linux Driver Development!
> > From:       devzero () web ! de
> > Date:       2007-02-04 21:37:33
> > Message-ID: 1605445807 () web ! de
> > [Download message RAW]
> > 
> > First off, compliments to this announcement, I liked it very much!
> > 
> > Some comment regarding those "volunteers, waiting to get some real work" :)
> > 
> >>> OK, but why isn't your army of volunteers fixing them?
> > 
> >> They don't know about them, or they don't have the hardware to test?
> >> Seriously, let the kernel-janitor's project know about any issues you
> >> have and they will be glad to jump on it.  Those people are just
> >> chomping a the bit to do something a bit bigger than "compiler warning
> >> cleanups" :)
> > 
> > So many times i have seen good ideas brought up, kernel patches being written, posted \
> > to lkml, being developed outside mainline for a while and then being forgotten some \
> > time later due to lack of energy of some individual to get this into mainline.
> > 
> > If there is an noticeably number of talented programmers (unfortunately, i`m not) , \
> > so why not "feeding" them the right way ? Where is those public and transparent and \
> > moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with \
> > sort of a "vote for this feature"-button, so those guys have something they can pick \
> > up? There is so much great stuff and ideas out there where they could put their work \
> > onto or getting involved, it just needs to be found or sort of being "managed" a \
> > little bit better.
> > 
> > For myself, i`m waiting for so quite some things to get "one step further", but they \
> > are more or less tied to some single individuals, for which you just cannot send some \
> > "hey, what`s up with your project"-message every second day. The interest in many \
> > nice projects often is quite low and evolution quite slow, but not only because of \
> > the fact that they aren`t great, but more because of not getting widely known. It`s \
> > not always missing specs, it`s also some missing noise/feedback for different \
> > features or missing of some "driving force" to bring things forward. How should one \
> > developer know that somebody needs a feature if those who could probably need it \
> > don`t request it? Maybe just because of the fact that they even imagine that such \
> > feature would be possible ?
> > 
> > Where is those efforts for fixing/integrating fantastic cowloop?
> > What about badram/badmem patch ?
> > Compressed Ccaching ?
> > Somebody helping with development of dm-loop or extend loop.c to support more than \
> > 256 devices ? Replacement of proprietary, unstable and unelegant vmware-lopp for \
> > being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace \
> > could be some infrastructure for this, but the author seems to have other \
> > priorities.... dm-cow, zfs-fuse - anybody ?
> > Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent \
> > implementations, but both got stuck at some early experimental stage) 
> > 
> > Just my 2 cents. 
> > 
> > Roland K.
> > Sysadmin
> > 
> > ps:
> > This isn`t meant to criticise any of you kernel developers since you`re doing \
> > fantastic work!
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > 
> 
> 
> -- 
> Bill Davidsen <davidsen@tmr.com>
>    "We have more to fear from the bungling of the incompetent than from
> the machinations of the wicked."  - from Slashdot
> 
> 


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

Re: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)

[devzero]

>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 iŽm 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