[ overview | motivations | results | contact | download | xen | links | Rick van Rein ]



BadRAM: Download area

This patch is free to download and use, according to what's stated in the GPL, but if you feel a desire to return a favour, I suggest you do do something environment-friendly and thereby help us all.

Keep up to date with RSS: A very low-traffic RSS feed is now hosted by OpenFortress, my own crypto-technology company. You can pick up the feed (and a few others that may interest you) from the news page at OpenFortress.

Support for x86_64 is present in recent patches, although it is not tested as often as the 32-bit versions. This means that a little tweak here and there may be called for. Do take care to extend the patterns from memtest86 to 64-bit numbers, as described in contained badram.txt documentation file.

BadRAM on Xen. This appears to be working, but has not been released. I am looking for test modules (DDR1 DIMM) with the usual static discharge problems, so I can test it on AMD64. Please see the page BadRAM on Xen for more information.

Kernel versionPatch(es) plus release docs
Xen-3.2.1Please contact me if you would like to test BadRAM on Xen.
2.6.28This patch was supplied by Sebastian Geisler who published it on his website (albeit as a reverse patch). There was a flaw in my manual reversal, which is now corrected here.
2.6.27This time, the first patch submitted was by Anup Shan who tested it on x86_64. It is based on Manish Pandya's work. Antoine Frénoy found compiling errors on i386 and created this improvement for it.
2.6.26Once again, Manish Pandya supplied a patch. It has been tested on i386 but should work on 64-bit as well. Anup Shan reported that the patch fails on 64-bit, so all future use and development should start from his improved patch.
2.6.25Equally valid patches were submitted by Sebastian Maar and Manish Pandya -- and I have to apologise for currently being so involved in Permaculture that I could not make them available immediately.
2.6.24Sebastian Maar provided the first patch, and because it took me 2 days to process it, Patrick Moran already submitted an alternative patch although he doesn't call himself a kernel hacker. Augusto Born de Oliveira brought me a corrected patch that ought to work best.
It has been like this for a long while now -- the patch is straightforward to port, and people who track new kernels send me theirs. Wonderful job, all of you avid supporters!
2.6.23Manish Pandya was the first to submit a patch. Philippe Wautelet found a small point of improvement that made the patch run stable on his 64-bit machine. Download the new patch instead of the previous one.
2.6.22Manish Pandya was the first to submit a patch, once more, and thanks to him it ended up here within 24 hours after the new kernel was released!
2.6.21Manish Pandya sent me one more patch.
2.6.20Manish Pandya sent me a patch. He also offers a Fedora patch on his site. Untested, please let me know if it works.
2.6.19Once more, Michal Schmidt sent me a patch withing 24h! His patch is now available and is expected to work fine. Please read the remark about BadRAM in mainstream kernels above this download area.
Another patch from Manish Pandya adds export of kernel parameter parsing but is otherwise the same.
2.6.18Once more, Michal Schmidt was faster than lightning! His patch is now available. It's operation has been confirmed by Jon Reed.
2.6.17A version-updated patch by Michal Schmidt again! His patch boots properly, and after a few confusing reports by people with less building experience, it has now been reported to work by a few others.
2.6.16Within hours after the release of the kernel, we have a patch for 2.6.16, thanks to the fast work of Michal Schmidt! This patch boots properly on i386 and x86_64 computers, and has been tested and approved on i386 by Xavier.
2.6.15None yet. Please start from the 2.6.13 patch which includes preliminary x86_64 code if you want to offer me your 2.6.15 patch. I will not be posting any further i386-only patches, because I want the 64-bit code integrated. It is the best path forward, even if most people today cannot test the x86_64 code themselves.
In the end, I'm sure this is the best for the BadRAM community as a whole.
2.6.142.6.14.1 patch by Max Kellerman. It lacks the experimental x86_64 code from 2.6.13.1 -- I am looking for re-integrations. For this reason, do not use this patch as a basis for further development.
2.6.132.6.13.1 patch by myself (Rick van Rein).
Contains an attempt to code for the x86_64 bit architecture. Unfortunately, remote debugging on someone else's machine didn't suffice to make me finish this chore. The x86 code is based on a submission of Hector Martin.
2.6.122.6.12.1 patch, constributed by Michal Schmidt.
Sebastian Chaumat reported "2.6.12.1 patch work perfectly for months here."
2.6.112.6.11.1 patch, constributed by Charlock.
Untested, please let me know if it works!
2.6.102.6.10.1 patch, constributed by Higuita, see 2.6.10.3 for an improvement. And another patch from Eric Holk, specifically for Gentoo Linux, r6 (I shouldn't be doing this, putting derived-Linux-patches on here, I know). Finally, Nathan Fredrickson reported problems compiling 2.6.10.1 without the CONFIG_DISCONTIGMEM flag. He therefore submitted an improved patch.
Untested, please let me know if it works!
2.6.92.6.9.1 patch, constributed by Marcus Better. And another patch from Bart Janssens and yet another patch from Higuita.
Untested, please let me know if it works!
According to Ryan Duffner, these patches did not work on his RHEL4-based system, so he offered a patch for the 2.6.9-5.0.3 CentOS4 kernel.
2.6.82.6.8.1 patch, constributed by Marcus Better. Works without issues according to Geoff Simmons.
2.6.52.6.5.2 patch, constributed by Domen Puncer.
Confirmed to work.
2.6.42.6.4.2 patch, constributed by Domen Puncer.
Untested, please let me know if it works!
2.4.232.4.23.1 patch, constributed by David Stahl. And here's another patch as well.
Untested, please let me know if it works!
2.4.222.4.22.1 patch, constributed by David Stahl.
Tested and approved by Rodrigo Oliveira.
2.4.202.4.20.1 patch, constributed by Michael.
Untested, please let me know if it works!
2.4.192.4.19.1 patch, constributed by Kristian Peters.
Untested, please let me know if it works!
2.4.162.4.16.1 patch, constributed by Juan Carlos Castro y Castro.
Untested, please let me know if it works!
2.4.4Seems to work with the 2.4.0 patch (reported by Sebastien Chaumat)
You may prefer Eric Methorst's slightly adapted patch.
2.4.32.4.3.1 patch, constributed by D. Sterba.
Untested, please let me know if it works!
2.4.02.4.0.1-alpha1 patch dd. Feb 14, 2001, which apparantly works nicely, with the following alpha release remarks:
I patched the source code of a 2.4 tree in the Feb 10/11 weekend, and it compiles. A \beta patch may be expected this week (soon, if nothing goes really wrong --- such as RSI, so it'll be delayed again).
Problems I still haven't cracked, and to which I welcome solutions are:
  • Is high memory already "mounted" before mem_init is invoked?
  • Before invoking mem_init, the value of mem_map is known, but it's upper bound max_mapnr is not. How to test an address for being `in range', or is there no danger in jumping out of this array?
So far, BadRAM patterns seem to discard memory just right; at least that's what's logged at boot time. I should compile some kernels on my bad, bad RAMs to be "certain".
2.4.0-testN
(instable kernels)		Many fancy debugging features were added by Nico Schmoigl, but beware... we found that not all of them worked. The patches work, but they are not as minimalistic as my original work.
Furthermore, his work is strictly aimed at i386.
You will find Nico's page here. He's been a really enthousiastic co-designer for a while, with whom I've had lenghty discussions --- thanx, Nico!
2.2.19
2.2.19.1 patch A and patch B.
Contributed by (A) Ron Yorston and (B) D. Sterba.
B is currently untested, please let me know if it works!
2.2.17
2.2.17.1 patch and release doc
(a.k.a. V3.3 of the patch)
Contributed by Stefan Illy.
2.2.162.2.16.1 patch and release doc
(a.k.a. V3.2 of the patch)
2.2.15
(kernel with security hole)		2.2.15.1 patch and release doc
(a.k.a. V3.1 of the patch)
Contributed by Wizard <ivs@writeme.com>
2.2.142.2.14.3 patch and release doc
(a.k.a. V3 of the patch)
2.2.14.2 patch and release doc
(a.k.a. V2 of the patch)
Always enter an even number of parameters after badram= and it works fine.
2.2.14.1 patch without release doc
(a.k.a. V1 of the patch, formerly unpublished)

About version numbers: The versions of the patch are sub-numbers of kernels. So 2.2.17.1 is the first patch version for kernel 2.2.17. Anything after this number is intended to scare you off unless you know what you do (in which case I value your bug/success reports), where alpha is scariest, beta is a bit scary, and rcN marks a release candidate. All these `scary' versions are subject to a temporary life.

About patching a kernel: Information for patching newbies is here. Please don't contact me about such trivialities, BadRAM costs enough time as it is...

Related software adaptions for BadRAM

Most of these are now part of the software they adapt...