BadRAM: Szegény ember RAM foltozója (a 2.6.0-test1 kernelhez is)

Címkék

Manapság egyre kisebbek a RAM chipek (köszönhetően a nagy RAM igényű alkalmazásoknak, egyre több chipet integrálnak a gyártók a RAM modulokra, következésképpen a chipek mérete egy kisebb lesz, vagy belső felépítésük lesz egyre bonyolultabb), ami miatt a RAM chipek sokkal sérülékenyebbek. Sajnos elegendő ahhoz, hogy dobhassuk ki az egész modult, hogy egy RAM modulon egyetlen bit hibás. Az olcsó asztali gépeknél - amelyekben általában noname gyártók által forgalmazott RAM-okat szerelnek - ez nem is jelent akkora problémát, hiszen ezeknek a moduloknak az ára elenyészik a gép árához képest. A gond inkább a komolyabb szervereknél van, ahol követelmény a minőségi ECC (error check & correction - hibajavító képesség), registered RAM modulok használata. Ezeknek a moduloknak az ára nem kevés, és nagyon tud fájni anyagilag, ha a garancia letelte után ezek a moduok meghibásodnak (itt nyilván kivételt képeznek a Lifetime garanciával árusított komolyabb modulok, mint például a K****tone). Vagy a másik nagyon kellemetlen dolog, ha egy notebook alaplapjára forrasztott RAM chip hibásodik meg. Ennek a javítása rendszerint a notebook alaplapjának cseréjével jár.

De nem kell annyira elkeseredni, mert van szaknyelven szólva "workaround" a dologra.Létezik egy projekt, amelynek az a célja, hogy a meghibásodott RAM modul hibás részeit "elfelejtesse" a Linux kernellel. Azaz a projekt által készített kernelfolt felkészíti a Linux rendszermagot arra, hogy a paraméterben megadott RAM területeket egyszerűen hagyja figyelmen kívül.

A projekt neve BadRAM. A működése egyszerű. A hibás RAM-mal rendelkező gépen lefuttatjuk az ismert RAM tesztelő programot a Memtest-et. A teszter által rossznak jelzett területeket rögzítjük, átalakítjuk a BadRAM által értelmezhető alakra, amellyel aztán úgy bootoljuk be a Linux kernelt, hogy a loadernek paraméterként megadjuk a hibás memóriaterület címeit. Valahogy így:

LILO: linux badram=0x008042f4,0xff805fff

Ezzel tudattuk a Linux kernellel, hogy mely az a terület, amelyet nem szabad allokálnia. Az ellenőrzéshez futtassuk a dmesg programot:

dmesg | grep ^Memory:

Memory: 158524k/163840k available

(940k kernel code,

412k reserved,

1856k data,

60k init,

0k highmem,

2048k BadRAM)

Amint látjuk, a memóriában 2MB-nyi hibás területet detektált a kernel.

Ha valakinek kényelmetlen a loadert paraméterezni, és kicsit jártasabb a kernelhackelésben, akkor a rossz terület adatait fixen is bele tudja drótozni a kernel forrásába.

A készítő szerint az alábbiak miatt van létjogosultsága a projektnek:

- a chipkészítés erőforrásigényes: veszíts kevesebbet, aludj jobban

- ez is egy módja annak, hogy bizonyítsák, mennyire flexibilis operációs rendszer a Linux

- a fent említett laptop kérdés miatt

- mert egyszerűen cool ;-)

Megjegyzés: azért a "produktív" környezetben a biztos megoldás a rossz modulok cseréje!

A BadRAM patchek elérhetőek a projekt honlapján. Folt a 2.6.0-test kernelhez a fejlesztő levelében.



További kapcsolódó HUP cikkek itt.

Hozzászólások

Egyebkent egy ideje mar megtalalhato a WOLK-ban is ez a patch ;)

tenyleg jo stuff a badram&memtest paros,

hasznaltam is egy darabig. Persze nem mindenhol hatasos ez sem, cimhibas moduloknal peldaul mar nem is olyan hasznalhato. Ugyanis az ominozus hibas resz merete, elhelyezkedese(elszortsaga), valamint a shadow memoriateruletek miatt inkabb a memoria csereje javasolt...

Arrol nem is beszelve, hogy a kutya is oda sz*rik, ahol mar van, azaz egy szar memoriamodul maximum meg rosszabb lesz.

asd

Ez a Spectrum (48k) esetén már bevált, csak az hardverből csinálta :)

Hat nekem van egy freebsd boxom, 486 proc, 32 mega ram, freebsd 4.7-rc, meg egy 3GB badsectoros hdd, ami felett mar nem bootolt a WinNT. Olyan 300 napos uptime-mal megy, es le se szarja a badsectorokat ;-)