Kernel panic eros HDD terheles eseten

Konfiguracio:
Intel DH57JG lap, i3-540 CPU, 2x2G Corsair RAM, 3x1.5 TB Samsung Ecogreen F3 HDD, ebbol sdb/sdc RAID1-ben.
OS: Debian Squeeze
A RAID vezerlest az alaplapi kontroller + mdadm vegzi. Az mdadm verzio ebbol kovetkezoen 3.1.3 (az Ubuntuban meg jelen levo 2.6.3-as mdadm nem kezeli nativan az Intel Matrix Storage Managert.)

Jelenseg:
Ha valamelyik koteten eros terheles van (pl. a RAID1-es kotetrol tar-olok fajlokat az sda-ra), akkor idonkent kernel panicot kapok. Sajnos a panic log meg nincs meg, megprobalom netcattal megoldani este (ha sikerul reprodukalni).

Egyeb informaciok:
Az egesz ejszakas memtest86 teszt 0 hibaval zarult.

Kerdes:
Van valakinek otlete?

A "ne hasznalj Linuxot" kevesse hasznos, jo ok van arra, hogy miert pont az van a gepen, es nem Windows vagy BSD.

Koszi.

Hozzászólások

mdadm helyett dmraid esetleg?
(egyébként nem is tudtam, hogy már mdadm is tudja kezelni a matrix bigyót, de most megnéztem és tényleg.)

Hát vagy a másik lehetőség, hogy soros porton nullmodem kábellel összedugod másik géppel, kernelnek ttyS0-t, konzolnak, másik gépen minicom vagy valami figyel...
Egyébként így minden info nélkül, lehet a hiba simán hardvertől is (vezérlő, hdd, cpu cache, vagy akár memória is)
--
Discover It - Have a lot of fun!

Igen, logot megprobalok majd csinalni. Hardverhibat nagyon nem szeretnek, az maceras lenne; a memoriat ugye tobbe-kevesbe kizarhatjuk (a memtest miatt). Lehet, hogy kikapcsolom az alaplapi vezerlot, es hasznalok sima softraidet, meglatjuk, mi lesz.

----------------------
while (!sleep) sheep++;

Epp most fejezodott be az sda es sdb tesztje (reggel beinditottam).

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 146 -

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 146 -

Egyebkent siman intenziv merevlemez-aktivitassal nincs gondja -- multkor aramkimaradas (khm..) miatt resyncelte a teljes tombot, kb. 3 oraig tartott, semmi problema nem tortent. Kifejezetten akkor van gond, ha a RAID tombre/tombrol masolok.

----------------------
while (!sleep) sheep++;

+1 a sima softraid-nek, az alaplapi vezérlő nemsokat segít szerintem a raid-nek és az i7-es CPU meg körberöhögi a RAID5-ös számolgatást valszin. Az is a softraid mellett szól, ha már nincs rendes raid kártya, hogy egyszerűbb tetszőleges másik gépen összerakni a tömböt.

Az ext4-el nem hiszem, hogy gondod lesz bár még jönnek hozzá a bugfixek sorban, de az Ubuntuban levő kernellel használom egy 6x2TB-os RAID5-el (backup gép) és sok hónapja megy. A 3x1,5TB-ot érdemes úgy felosztani hogy 3 darab kisebb partició raid1-ben (vagy két partició+hotspare) és a három nagyobb partició pedig raid5-ben. (A particiók pontos száma nyilván ízlés és szükség kérdése, ez csak alapötlet.)

Ha OS-t cserélsz, akkor szerintem totálisan mindegy lesz, mert új FS-t akarsz rátenni.

nem tudom, mi a fájdalmas benne, de én sokat használom a dmraid-et (igaz én csak raid0-t használok) és lekopogom, még soha nem volt vele semmi gondom. gondolom a megbízhatóság megér annyit, hogy a "fájdalmasságot" elviseld :)
de legalább egy próbát megérne, aztán ha azzal működik, akkor mehet az mdadm-ről a bugreport.
vagy esetleg kapcsold ki a raid romot, és csinálj tisztán szoftveres raid-et mdadm-el.

Valószínü.
Hadd kérdezzem meg ,hogy milyen tipusu diszkek vannak a tömbben ?
Nekem a WD black-kal állandó random problémáim voltak kernel panic is.
Windows XP alatt is problémás volt.
Azóta az egyik disk megadta magát láthatólag minden ok nélkül.
Most Samsungok vannak ugyan ott és azóta nincs hiba. (3 hete) .....?
Az is igaz hogy azóta a vezérlőn nincs single disk.
Gondoltam arra is ,hogy nem bios hiba e mert esetleg a RAID módban gondja van a single diszkel.
Alaplap GA-H57M-USB3.

Update:
Megjött a WD black a gariztatásból.
Beteszem ugyan úgy eszi a fene pedig most nincs single diszk.
Bios update után ugyan az a gond linux alatt , de WIN XP alatt mostmár stabil.
Ugyanezek a diszkek stabilan mennek GA-MA78GM lappal.
Köcsönkértem egy GA-H57M-USB3 rev2 lapot és azzal kigyógyult.
Most valami hackelt biost keresek ami javítja az intel raid matrix firmware-jét.

Valószínűleg disk firmware lehet az oka.
Volt olyan tapasztalat bizonyos Samsung vinyókkal (EcoGreen F4), hogy terhelés alatt random resetelték magukat ás eldobálták az adatokat.
Állítólag a queue depth-el függött össze a dolog, én nem szórakoztam a probléma kimérésével, hanem kapásból kicseréltem az összes vinyót.
A dmesg-ben drive reset-re vagy timeout-ra keresgélj, talán nyomra vezet.

Naná, hogy cpu-igényes: valakinek azt a rahedli xor-t meg kell csinálnia :-) - vagy a cpu-nak, vagy a raid chipnek. Ráadásul a fizikai i/o-ban sem mindegy: az átlagos alaplapi raid vezérlőnek elég egyszer kiküldeni a kiírandó adatokat, ő majd továbbtolja a két diszkre (sima tükör esetén), míg a fullos szoftraid-nél a két diszket külön kell etetni.

memtest, cpubourn volt már?

hátha máshol van a baj