[needs-packaging] BadRAM Linux Kernel Patch

[Bryan Quigley]

This is a packaging request for the BadRAM Linux Kernel patch available for free under the GPL here: http://rick.vanrein.org/linux/badram/

About BadRAM
"My objective is to patch the Linux kernel in such a way that it can handle defective RAM modules. With defective RAM, I mean RAM which has some bits wrong at some (known) addresses. Normally, such RAM is considered useless and thrown away; the larger RAMs get, the higher the chances of failing addresses. With ever growing RAM sizes, it would therefore be pleasant to have an alternative to discarding of defective RAM chips."

Instead of requesting this patch be added to the default linux kernel which has been invalidated in many bug reports in the past, this is a request for the patch to be packaged. Perhaps it could be packaged similar to *-kernel-source, linux-patch-*, or kernel-patch-*.

[Shirish Agarwal (shirishag75)]

That would be cool. Subscribing to the request.

[SneakyWho_am_i (sneakywho-am-i)]

I have a use for this, it's worth a couple of hundred dollars to me.

One day perhaps the boot managers, kernel and memtest will all work seamlessly together to identify, flag and dishonour bad ram (meaning, by downloading a metapackage and running memtest86, perhaps you could automatically flag the bad RAM)...... I know that's outside of the scope of this report, but it's OK to dream, right?

Yes, though, I'm for this package in a big way.

[pivo (pivo-pobox)]

If I get it right, there's no need for badram patch unless bad bytes are spread all over the map. With a bit more manual effort one can use memmap=exactmap parameter already present in current kernels.

A howto for 2.6.25 kernels: http://groups.google.com/group/fa.linux.kernel/msg/d90e920265afafd8 .

In 2.6.24 one needs to look up the bios provided memory map from the beginning of the dmesg output. Then convert the map to the memmap= format and merge with the bad memory block(s) to be reserved.

And last but not least, if it's worth a couple of hundred dollars to you, if you provide a financial incentive, someone might as well step up and come up with something that'd serve your needs.

[SneakyWho_am_i (sneakywho-am-i)]

Oh wow!
I must not have looked hard enough(.!!) as all I could find was badram. I was shocked that nothing like it was packaged or anything. Someone, through a forum system, somewhere, claimed that badram was my only option in software, and I believed it.

>And last but not least, if it's worth a couple of hundred dollars to you, if you provide a financial incentive,
>someone might as well step up and come up with something that'd serve your needs.

I never did quite get to the point of offering money for it, but I was approaching it...
pivo... Thank you. And thank you again.
While I still think that it would be invaluable to have the badram patch as a package, I'm stoked to learn about this other thing from you (but now i have to figure out how useful that is for me, and then use it...) Would the badram patch be a lot of extra work for someone to maintain as a package, with the rate at which kernels are released??

[Bryan Quigley (bryanquigley)]

Yea.. I was reading the lkml and apparently the creators of badram hadn't
heard of it either.

[Shirish Agarwal (shirishag75)]

GQuigs, cannot understand what u mean by that. A link to the lkml where you read whatever u read would be helpful.

[Shirish Agarwal (shirishag75)]

An interesting thing mentioned in one of the pages is http://rick.vanrein.org/linux/badram/download.html

Specifically this part :-

BadRAM in mainstream kernels? I have submitted the patch to the kernel and memory management maintainers on March 2nd, 2008. I am looking forward to reporting good results on that. Meanwhile, since patch submission is not the most obvious process, this site will be maintained as before. I welcome new patches on new kernel versions as usual, preferably made with diff -pruN.

It would be nice if this gets included in the mainstream kernel, what do you guys think?

[Bryan Quigley (bryanquigley)]

They submitted it and then discovered memmap could do some (most?) of what
badram does apparently. The whole thread is an interesting read:
http://lkml.org/lkml/2008/3/11/319

Memmap "can" do what badram does, (I think) but I have yet to really get it
working. I would love to see the badram option added to mainline instead of
packaged seperately.

[Tom Arnold (g0tt)]

Pivo, that posting is hardly a howto IMHO.

So is there any kerneloption to map bad memory in 2.6.25 or not?

[Bryan Quigley (bryanquigley)]

Tom: Unfortunately that posting is it for now...

[Michael Rooney (mrooney)]

A very neat idea! I agree this is really useful, especially in cases such as soldered memory where you can't just "buy new memory" (which is a pretty ignorant argument to begin with anyway).

From reading the mailing list article from gQuigs, it sounds like memmap works fine and is already included, but its syntax is not as nice (primarily for patterns). However someone also mentioned they would take up adding badram syntax to memmap so users could use the same lines from memtest86. That would then I think satisfy everyone here.

From here the next logical step is automatically detecting bad ram and guiding the user through the process to fix it. If this is Fixed, or Invalidated by memmap improvements, a blueprint could be made for this process.

[Tom Arnold (g0tt)]

Well, no need for automation at the moment. A simple boot option and a small howto on converting memtest output to that boot option would be totally sufficient for me right now.

Will this be in Intrepid?

[Shirish Agarwal (shirishag75)]

Bumping/looking for comments on this one .

[Bryan Quigley (bryanquigley)]

I wrote a howto:
http://gquigs.blogspot.com/2009/01/bad-memory-howto.html

It is for all intensive purposes just as easy as using the badRAM patch. (And I have been running with the memmap options for some time now with no issues).

I'm thinking about closing this bug, does anyone still have a use for the badRAM patch after using my howto?

[StoatWblr (stoatwblr)]

Badram has other uses for eliminating issues like memory holes, etc.

I have an Intel 865GLC motherboard. There are lockups if memory around 4077Mb is addressed - even though there's only 2048Mb onboard. Memtest86+ reports the errors when scanning memory, then freezes solid.

I want to try and tell the kernel not to address the area (4077-4096Mb), etc. Any ideas?

[Bryan Quigley (bryanquigley)]

Would that be part of SWAP space or something else?

[jv13613 (jv13613)]

debain already has a package.

http://packages.debian.org/stable/devel/kernel-patch-badram

[Bob/Paul (ubuntu-launchpad-bobpaul)]

Grub2 has a BadRAM option. It looks like the default /etc/default/grub file on Debian Squeeze explains it's use, along with the Grub2 documentation: http://www.gnu.org/software/grub/manual/grub.html#badram Since we now use Grub2, this is probably the correct way to handle and document this feature. Appears to be something like GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" and the format of address,mask,address,mask,... is the same as the BadRAM patch uses.

Can someone with defective memory test this works as described? If so, we should update the community documentation: https://help.ubuntu.com/community/BadRAM

[Robert Millan (rmh)]

Hi,

> Can someone with defective memory test this works as described?

I'm one of the GRUB developers. We've tested this feature, in fact I tested it myself, I've been using it on my laptop for several months with no problem whatsoever.

> If so, we should update the community documentation: https://help.ubuntu.com/community/BadRAM

Yeah, please do.

Thanks

[Michael Rooney (mrooney)]

So, shall we mark this bug as Invalid then, if the feature exists in GRUB already?

[Bryan Quigley (bryanquigley)]

Invalidating.. Since there are two alternative solutions (memmap and grub options) and it seems like interest upstream is slowing...