[Linux] BadRAM/BadMEM patches

[WildernessChild]

Voor de Linuxkernel bestaan patches genaamd BadRAM en de uitgebreidere versie daarvan, BadMEM, die ervoor zorgen dat je rotte plekken in je geheugen kunt omzeilen. Helaas krijg ik deze niet aan de praat.

Ik heb Rick van Rein, de auteur van BadRAM, hierover gemaild, maar daarop geen antwoord gekregen, vandaar dat ik het hier vraag. Ik ben lui en zal daarom het relevante stuk van het mailtje posten. Ik weet dat hij waarschijnlijk Nederlands kan, maar better safe than sorry

quote: mailtje

Unfortunately, I cannot get the patch to work. I use a clean 2.6.5 kernel source tree and apply the patch, which compiles fine and has some result. That result is something like:
Uncompressing Linux... ok, booting the kernel...
And then the machine hangs. Funny thing is that the bad RAM is not even installed yet; there is only a strip of 128 MB of 66 MHz DIMM which is perfectly alright according to Memtest86 Almighty.

A kernel without the patch and the same configuration works fine. I also tried it on a 2.6.4 kernel; this hangs as well. Without the "badram=..." parameter, the kernels boot fine. The BadMEM patch for the 2.6.4 kernel won't compile, so I cannot tell wheter that one does work.

The .config file (generated by "make menuconfig") used to build the 2.6.4 kernel is attached to this e-mail (the pc only has 2 GB of HD space so I had to erase the 2.6.5 source tree and forgot to backup its .config). I also attached the lilo.conf where you can see the boot options used.

Verder nog:

quote: http://lilo.conf

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/hda
message = /boot/boot_message.txt
prompt
timeout = 50
default = linux-2.6.5-brp
# Override dangerous defaults that rewrite the partition table:
change-rules
reset
# 2.6.5 with BadRAM patch
image = /boot/kernel-2.6.5-brp
root = /dev/hda1
label = linux-2.6.5-brp
append = "badram=0x00dc0800,0x00dc0800,0x01901000,0x01901000"
read-only
# 2.6.4 with BadRAM patch
image = /boot/kernel-2.6.4-brp
root = /dev/hda1
label = linux-2.6.4-brp
append = "badram=0x00dc0800,0x00dc0800,0x01901000,0x01901000"
read-only

Ik zal niet de hele .config posten, maar volstaan met zeggen dat CONFIG_BADMEM=y erin staat

Oh, voor zover dat uitmaakt, het gaat om Slackware 9.1 op een Compaq DeskPro 266 MHz machine.

Ik hoop dat hier slimme tweakers zijn die kunnen helpen met dit probleem!

[cool_zero]

Rick spreekt gewoon nederlands , maar een engels mailtje zal die ook wel kunnen lezen Aan de sites te zien wordt het badram niet zo erg meer onderhouden aangezien de laatste patches allemaal niet getest zijn. Ik vermoed dat deze patches wel goed zouden moeten werken op een 2.6 kernel van kernel.org (en niet die van suse ofzo) Gaat het patchen wel helemaal goed? geen .rej files?

Als het BadRam niet werkt kun je natuurlijk altijd het actievere project BadMem gaan gebruiken.

[Warbringer]

cool_zero schreef op 24 mei 2004 @ 22:48:
Als het BadRam niet werkt kun je natuurlijk altijd het actievere project BadMem gaan gebruiken.

[overbodig]
Of nieuw geheugen halen :-)
[/overbodig]

[Wilke]

Je kunt de patch wel 'clean' applyen, dus geen warnings whatsoever?

[it0]

In de wolk kernel zitten ookde badram patches, misschien kan je die eens proberen.

[WildernessChild]

Bedankt voor jullie reacties!

@Warbringer: ik wil het juist zo werkend krijgen, ik ben nou eenmaal erg eigenwijs

2.6.5 is "confirmed to work" op de BadRAM site; ik gebruik natuurlijk een cleane kernel.org source tree.

Als patch waarschuwingen geeft, stopt ie dan? Want hij gaat in een keer door, hoewel ik de output niet grondig bekeken heb. Ik kan me misschien wel vaag iets herinneren van "patch succesfully applied".

Zoals ik schreef, BadMEM krijg ik niet gecompiled. Maar ik zal daar eens op gaan focussen dan

[ Voor 14% gewijzigd door WildernessChild op 25-05-2004 18:37 ]

[Valium]

Nee, als er zogenaamde rejects zijn, stopt 'ie niet. Hij slaat de mislukt patches op in een reject-file zodat je die later met de hand alsnog kan doen. Je kunt kijken of alles is goedgegaan door de opdracht

code:

find -name *.rej

uit te voeren. Die zal alle bestanden die eindigen op .rej vinden.

[WildernessChild]

Goed, zojuist heb ik de BadMEM patch geprobeerd, met "extended module support" (geheugenmodules, niet kernelmodules ). Keurig een /etc/badmem.conf gemaakt volgens Documentation/badmem_conf.txt, als volgt:

code:

module slechte128
        size 128m
        base 0m
        0x00dc0800,0x00dc0800
        0x01901000,0x01901000

module goede128
        size 128m
        base 0m

Maar make zegt nu het volgende:

code:

BadMEMlib version 1.6.0
$Id: lib.c,v 1.21 2004/03/16 16:20:59 eagle2 Exp $
$Id: hash.c,v 1.7 2004/03/16 13:58:54 eagle2 Exp $
$Id: mdf.c,v 1.15 2004/03/16 13:58:55 eagle2 Exp $
$Id: patn.c,v 1.21 2004/03/16 13:58:55 eagle2 Exp $
$Id: type.c,v 1.6 2001/08/14 15:02:53 eagle2 Exp $
rm -f mm/badmemlib_version  # This file is not used any more, so we can delete it
gcc -o mm/modparse mm/modparse.c -lbadmem -lm
mm/modparse /etc/badmem.conf > mm/badmem_modules.c
make[1]: *** [mm/badmem_modules.o] Error 139
make: *** [mm] Error 2

Okee, dan met de hand:

code:

root$ mm/modparse /etc/badmem.conf
#include <linux/badmem.h>

/* MDF CMD set in clear text is as follows:
Command [000]:  VERSION 1
Command [001]:  MODULENAME len=8, slechte128
Command [002]:  MODULESIZE len=4, 134217728
Command [003]:  PATTERN type=3, len=16, 0x00dc0800,0x00dc0800(0xffffffff/0x00000
000)
Command [004]:  PATTERN type=3, len=16, 0x01901000,0x01901000(0xffffffff/0x00000
000)
Command [005]:  END
total length in memory: 68
*/

char mdf_slecht128[] = {
  0x01, 0x00, 0x01, 0x00, 0x10, 0x00, 0x00, 0x08, 0x67, 0x69, 
  0x6a, 0x73, 0x31, 0x32, 0x38, 0x00, 0x11, 0x00, 0x00, 0x04, 
  0x08, 0x00, 0x00, 0x00, 0x20, 0x00, 0x03, 0x10, 0x00, 0xdc, 
  0x08, 0x00, 0x00, 0xdc, 0x08, 0x00, 0xff, 0xff, 0xff, 0xff, 
  0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x03, 0x10, 0x01, 0x90, 
  0x10, 0x00, 0x01, 0x90, 0x10, 0x00, 0xff, 0xff, 0xff, 0xff, 
  0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00};

Segmentation fault

Blijkbaar wordt de configfile niet goed geparsed of zoiets... maar zonder de goede module erin doet hij het wel! Bug in modparse dus blijkbaar... kan iemand dit verifiëren met dezelfde badmem.conf? Die tweede (goede) module gaat er uiteindelijk wel uit, maar ik wil het toch graag voor elkaar hebben zoals het hoort

[WildernessChild]

Te vroeg gejuicht...

code:

  LD      .tmp_vmlinux1
mm/built-in.o(.text+0x1ae1f): In function `badmem_get_patternset_from_string':
: undefined reference to `kmalloc'
mm/built-in.o(.text+0x1af9e): In function `krealloc':
: undefined reference to `kmalloc'
mm/built-in.o(.text+0x1bd6d): In function `new_badmem_patternset':
: undefined reference to `kmalloc'
mm/built-in.o(.text+0x1bd96): In function `new_badmem_patternset':
: undefined reference to `kmalloc'
mm/built-in.o(.text+0x1bdc3): In function `new_badmem_patternset':
: undefined reference to `kmalloc'
mm/built-in.o(.text+0x1c073): more undefined references to `kmalloc' follow
make: *** [.tmp_vmlinux1] Error 1

kmalloc lijkt me toch een vrij essentieel iets... in welke object file zit dat, en waarom wordt het opeens niet meegelinkt? Als ik dit goed begrijp tenminste

Edit: "badmem kmalloc" is bijna een Googlewhack...

[ Voor 8% gewijzigd door WildernessChild op 26-05-2004 20:45 ]

[SvMp]

kmalloc is een kernel-functie. Die module kan deze functie niet vinden.
Is die module wel goed gelinkt?

kmalloc zit dus niet in een objectfile, maar in de kernel zelf!

[ Voor 224% gewijzigd door SvMp op 26-05-2004 21:25 ]

[cool_zero]

Ik denk dat het fout gaat bij het parsen van de config file. Ik vermoed dat dit komt door het missen(niet kunnen vinden) van de Badmem utils. Klopt dat?

Er staat namelijk in de howto:

For getting started you need the following files from the Internet:

* The BadMEM patch: ....

* The BadMEM utility package: Can be downloaded from http://
badmem.sourceforge.net, too. Besides it is required for the compilation of
the kernel, it provides several useful small utilities which could make
your life easier once you are a bit more experienced in BadMEM.

* The Linux Kernel: ...

* memtest86: ...

[WildernessChild]

Had ik dus eerst last van -- segfault bij modparse (zie boven). Nu heb ik het goede reepje uit de config file gesloopt en komt hij voorbij deze fase. Zo te zien gaat het mis bij het linken van de kernel image, waaruit ik denk te kunnen concluderen dat in de gelinkte object files geen kmalloc voorkomt. Maar dat zou wat vreemd zijn...

@svdmeer: kmalloc (de executable code ervan) zit inderdaad in de kernel zelf, zodra die gelinkt is natuurlijk Daarvoor komt hij (als het goed is) alleen voor in een of andere objectfile die wordt meegelinkt. Maar het is blijkbaar niet goed

[cool_zero]

Ik heb het ook even geprobeerd om badmem te compilen en het koste wel wat moeite om hem werkend te krijgen. Het is uiteindelijk wel gelukt. Ik heb deze config gebruikt om te kijken of alles goed werd gecompiled. Ik heb het verder niet getest daarna.

code:

module slechte 
    size 128m      
    base 0     
    0x00dc0800,0x00dc0800  
    0x01901000,0x01901000  
                         
module goede       
    size 128m 
    base 0

Het viel me op dat het patch-deel de headerfiles van het linux systeem gebruikte die in /usr/include staan en niet die van de kernel. Ik heb daarom maar wat gehacked daar om alles toch aan de praat te krijgen met de juiste headerfiles. (Een nieuwe versie van libc6-dev had misschien ook wel geholpen)

Ik heb een backup gemaakt van /usr/include/asm, /usr/include/asm-generic en /usr/include/linux. Daarna heb ik de headerfiles uit linux-source die staan in /usr/src/linux-2.6.4/include, dus de mappen asm(=asm-i386), asm-generic en linux naar de /usr/include gekopieerd. Daarna moest ik het volgende nog even aanpassen (in /usr/include/) omdat het anders niet werkte(de volgende keer maar even uitzoeken hoe het officieel hoort te gaan ):

in asm/mpspech.h veranderen van dit:
#include <mach_mpspec.h>
naar dit:
#include <asm/mach-generic/mach_mpspec.h>

en in asm/smp.h veranderen van dit:
#include <mach_apicdef.h>
naar dit:
#include <asm/mach-generic/mach_apicdef.h>

Hiermee kreeg ik de 2.6 kernel gecompiled met extended module support voor badmem aan. Ik zou me kunnen voorstellen dat als je te oude headerfiles gebruikt er problemen optreden met kmalloc.

[WildernessChild]

Ik moest nog even de gegenereerde autoconf.h kopiëren naar /usr/include/linux. Ook bleek het dat (wederom) modparse segfaultte op deze config, maar met de twee geheugenmodules in omgekeerde volgorde ging het wel goed.

Hij is nu net met succes gecompileerd, ik ga nu eens rebooten... ben benieuwd!

Edit: hij boot! Een hoop puntjes in beeld na "Locking memory", maar /proc/badmem/summary geeft inderdaad gelockte pagina's. Ik ga nu een kapot reepje installeren...

[ Voor 23% gewijzigd door WildernessChild op 29-05-2004 14:25 ]

[cool_zero]

Het klinkt positief, ik ga denk ik ook maar weer eens op zoek naar kapotte 1 gb modules

[WildernessChild]

Ik post dit nu vanaf de betreffende pc, met het kapotte reepje erin, en Firefox draait als een zonnetje. cool_zero, je bent geniaal! Ontzettend bedankt!