BadRAM Patch für Kernel 2.6.29
Aktuelles Diff: BadRAM-2.6.29.it-psycho.patch.bz2 (10,89 KB)
-
RSS Feeds
ArtikelKategorie
Archiv
- February 2012 (1)
- January 2012 (2)
- September 2011 (1)
- June 2011 (1)
- May 2011 (3)
- March 2011 (3)
- February 2011 (2)
- January 2011 (2)
- November 2010 (2)
- October 2010 (1)
- August 2010 (5)
- July 2010 (2)
- January 2010 (1)
- December 2009 (1)
- October 2009 (1)
- September 2009 (3)
- June 2009 (5)
- March 2009 (4)
- February 2009 (5)
- January 2009 (1)
- November 2008 (4)
- October 2008 (2)
- September 2008 (1)
- July 2008 (3)
- June 2008 (4)
- May 2008 (4)
- April 2008 (19)
Did you send your badram patches to Rick Vanrein? Would be nice to be able to find them there.
I found problem when compiling kernel (2.6.29.3 vanilla) with this patch. Patch applies clearly:
cd /usr/src/linux
patch -p1 < ../BadRAM-2.6.29.it-psycho.patch
patching file arch/x86/configs/i386_defconfig
patching file arch/x86/configs/x86_64_defconfig
patching file arch/x86/include/asm/page_32.h
patching file arch/x86/include/asm/page_64.h
patching file arch/x86/Kconfig
patching file arch/x86/mm/init_32.c
patching file CREDITS
patching file Documentation/badram.txt
patching file Documentation/kernel-parameters.txt
patching file Documentation/memory.txt
patching file include/linux/kernel.h
patching file include/linux/page-flags.h
patching file lib/cmdline.c
patching file lib/show_mem.c
patching file mm/page_alloc.c
then:
time make-kpkg –revision=1.0 –append-to-version=-badram kernel_image
[...]
CC arch/x86/mm/init_32.o
arch/x86/mm/init_32.c:442: error: expected ‘;’, ‘,’ or ‘)’ before ‘=’ token
arch/x86/mm/init_32.c:472: error: expected ‘;’, ‘,’ or ‘)’ before ‘=’ token
arch/x86/mm/init_32.c: In function ‘set_highmem_pages_init’:
arch/x86/mm/init_32.c:486: error: too many arguments to function ‘add_highpages_with_active_regions’
make[2]: *** [arch/x86/mm/init_32.o] Error 1
make[1]: *** [arch/x86/mm] Error 2
make[1]: Opuszczenie katalogu `/usr/src/linux-2.6.29.3′
make: *** [debian/stamp/build/kernel] Error 2
This is:
static int __init add_highpages_work_fn(unsigned long start_pfn,
unsigned long end_pfn, void *datax,
int* pbad = NULL)
{
exactly line with int* pbad = NULL)
Same thing happend when I tried to use patch 2.6.28. 2.6.25 with patch from http://rick.vanrein.org/linux/badram/download.html compiles and runs OK. My system is Debian Lenny (stable), GCC 4.3, 32bit. Any ideas, what may be source of this problem and how to solve it?
Please try
>CONFIG_NOHIGHMEM=y
># CONFIG_HIGHMEM4G is not set
># CONFIG_HIGHMEM64G is not set
CONFIG_NOHIGHMEM=y solved the issue. Thanks a lot!
Well, it seems that this patch doesn’t work. I patched (clearly) 2.6.29.3, installed it, passed arguments (kernel /boot/vmlinuz-2.6.29.3-badram root=/dev/hda2 ro badram=0×13832894,0xfffffffc) to the kernel, but when I copy large files and then check md5sums, they differ. Harddisk is OK, and when I copy and check md5sums on patched 2.6.25.19 (kernel /boot/vmlinuz-2.6.25.19-badram root=/dev/hda2 ro badram=0×13832894,0xfffffffc) it is OK, so it seems to be problem with patch.
What about vanilla 2.6.29.3? Did you check the md5 there, too?
You mean unpatched vanilla 2.6.29.3 and md5sums of those large files? No, I didn’t check. But I’m sure there will be errors – this RAM is corrupted since very long time (march 2006 at least), and there were always mismatched md5sums after running on vanilla kernel (and everything was fine on patched kernels). I try to avoid running on unpatched kernel – there always can occur filesystem corruption while running on broken RAM…
I wonder if new kernel options like skipping first 64 kB due to BIOS compatibility could have influence? I’m not sure if I turned this on… In theory it should not make a difference, but if addressation of memory changes (physical cells vs. kernel address), it will have influence…
As you probably noticed, this machine isn’t often turned on, so please, let me know what test should I do. I plan:
1. Check 2.6.29.x without skipping first 64 kB.
2. If there are errors, I’ll check 2.6.28.x
Anything else?
sorry to say this, but CONFIG_NOHIGHMEM=y is not a solution to compile a broken patch but only not compiling the patch. CONFIG_NOHIGHMEM=y will also “fix” all and only memory issues above the first GB – because this memory is just not used (with or without patch).
Yes, but only above the first GB of RAM. If you have =< 1GB it is still fine.
Well, after all, I gave up using BadRAM. I’m using build in kernel parameters, which allow (at least on non-distribution kernel, it didn’t work on Debian one) to exclude some region of memory. I wrote about it http://rozie.blox.pl/2010/01/Jak-bezpiecznie-korzystac-z-uszkodzonej-pamieci.html (Polish, so use translator please). There’s also simple script for testing without reboot (checksums compare before and after copy, in loop). And this method is kernel version independent (now running on 2.6.32.9).