[Megoldva] SATA adathibák jelzés nélkül

 ( XMI | 2012. december 29., szombat - 1:41 )

Eljutottam arra pontra, hogy már muszáj kérdeznem...

Adott egy alaplap (MSI MS-7519 Intel P43+ICH10 chipset), valamint egy (igazából több) Samsung 830 SSD.

A következő módon próbáltam az SSD-t tesztelni:

Teleírás "random" (de mindig reprodukálhatóan azonos) adattal:

dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample |  sudo dd of=/dev/sdb bs=8192

Visszaellenőrzés:

dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample |  sudo cmp -l - /dev/sdb

Normális körülmények között (pl a fenti SSD egy másik gépben) a cmp nem talál különbséget. Tehát az SSD és a tesztelési módszer alapvetően jó.

Viszont ebben a gépben talál különbségeket. Ez egy futásnál kapott példa. Az olvasást megismételve pontosan ugyanezt kapom vissza, viszont az írást megismételve más helyekre kerülnek a hibák, a számuk is kicsit változik +/- 1-2, de nagyságrendileg ugyanennyi marad.

          692658557  20 220
        29539541373 114 314
        60075553149 162 362
        75365245309 173 373
        82996355453 131 331
        90628153725 150 350
        98256822653  33 233
       105894486397 172 372
       113515381117 173 373
       143955181949 124 324
       159206035837  23 223
       182105842045 111 311
       197371572605  73 273
       205012619645 164 364
       220288868733  52 252
       235546464637  37 237

Annyi látszik, hogy a hiba nem az olvasás során kerül oda, hanem az írásnál - szar ügy. Továbbá a hibákban van rendszer, egyrészt az oktális számokból látszik, hogy mindig a byte lefelső bitje billen 0-ról 1-re, másrészt (ez ránézésre nem ennyire nyilvánaló, de binárisra átszámolva már igen), a cím alsó 12 bitje mindig azonos, 0x17d. Más rendszert nem találtam benne, és sajnos ez nem mond sokat a hiba okáról. Annyit talán igen, hogy mivel pontosan 1 bit tér el, ezért nem történhet paritással védett csatornán, mert annak meg kéne fognia.

A smart nem jelez UDMA CRC errort, vagyis az SSD nem érzi úgy, hogy a SATA fizikai rétegben gond lenne. Mivel ugyanez az SSD másik gépben hibátlanul veszi a tesztet, valamint a media read/write failure attribútumok is fixen 0-n állnak, ezért arra következtetek, hogy valahol feljebb lesz a hiba.

Hibát nem jelez:
- dmesg (3.6.10-1, x86_64 Arch linux)
- memtest86+ 4.2. Az 5-ös teszt akár órákon át futva is hibátlan (random memóriahibát ennek kéne megfognia).
- dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample | cmp - <(dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample) - hibátlan tehát nem a CPU hibázik a random stream előállítása közben

Nincs hatása:
- SATA port cserelgetés nem változtat
- SATA kábel cserélgetés nem vátloztat
- SSD cserélgetés nem vátloztat (olyan HDD most nincs kéznél, amiről törölhető minden)
- nincs tuning
- egyéb kártyák (tv tuner) jelenléte nem számít

Valamilyen szinten hatással van:
- Az déli híd hőmérséklete. Ha ventilátorral hűtöm az ICH10-et, akkor a ~16 hiba lemegy 4-7db-ra.
- Az ICH tápfeszültsége. A default 1.5V-tal a legjobb, magasabbra állítva valamelyest romlik. Lejjebb állítani viszont nem lehet.
- AHCI módból legacy IDE módba kapcsolni. Sajnos ez is csak ront a helyzeten. Amellett, hogy kb 20%-al lassabb, kb 2-3x annyit hibázik is.

Az ICH sajnos nem PCIe-n hanem valami Intel-proprietary DMI interfészen keresztül kapcsolódik az északi hídhoz. Nem találtam nyomát, hogy be lehetne-e kapcsolni a DMI linken olyan paritáshiba-jelzést, mint pl a PCI SERR#.

NMI viszont van, most éppen 2800 körül jár a számláló, és fogalmam sincs, hogy hogyan tudnám kideríteni, hogy mitől jönnek. Olyankor is jön, amikor a SATA porthoz hozzá sem nyúlok (az OS egy PATA diszkről megy).

Nem találtam módot arra sem, hogy a SATA2-es (3Gbit/s) jelzési sebességet visszavegyem 1.5Gbit/s-re. Mondjuk önmagában röhej, hogy mindenhol erre a módszerre hivatkoznak: http://www.ehow.com/how_7331892_set-sata-speed-adapter-linux.html ami akkora hülyeség, hogy párját ritkítja. man hdparm és rögtön látszik, hogy mekkora ökörség. Sajnos Alan Cox szerint korábban nem volt kivezetett interfész rá, a kernel magától visszaveszi a segességet, ha sokat hibázik port - feltéve ha észreveszi. BIOS-ban természetesen nincs állítási lehetőség.

Szóval most kicsit tanácstalan vagyok. A "dobd ki az alaplapot" jellegű megoldást magamtól is ki tudom találni. "Vegyél másik SATA vezérlőkártyát" - szintén. Rááadásul a PCIe x1 foglalatok is az ICH10-ből jönnek, tehát ha a hiba a DMI link környékén vagy az ICH10 belső PCIe bridge-ben van, akkor a kártyás SATA vezérlővel is hibázni fog. Parallel PCI szintén ICH10-ről jön, ráadásul SSD-hez az igencsak lassú is. Ezen kívül csak a PCIe x16-os van közvetlenül az északi hídról amiben a grafkártya ül - nehéz lenne ide rakni SATA vezérlőt.

Tehát valami szoftveres megoldás kéne, hogy üzemszerű működés során legalább jelezze, ha hiba van. Még jobb, ha esetleg javítani is tudja. El tudom képzelni, hogy ilyen hiba nem csak engem érint, csak éppen sokan nem is tudnak róla. Illetve ha kicserélem az alaplapot ki tudja, hogy nem ugyanilyen hibásat kapok-e. Tapasztalatból tudom, hogy egy OS simán el tud működni a hibás porton lógó SSD-ről futva úgy, hogy a user csak hébe-hóba egy-két érthetetlen furcsaságot tapasztal, de nem jön rá, hogy mitől. Lényegében már az segítene, ha írás után a kernel visszolvasná a kiírt adatot és 1) dobna errort, ha nem egyezik 2) esetleg megismételné az írást.

UPDATE: a megoldás végül elod kollégától jött. A sima memtest86+ helyett memtest86 4.0a multithreaded változat kellett, hogy kifogjon egy memóriahibát. A hiba címének utolsó 12 bitje egyezett a diszken talált hibák utolsó 12 bitjével (ami jogos, ha az adat többnyire egész page-enként másolodik a memóriábol). Erre lényegében csak ECC-s memória jelent korrekt megoldást, más integritás-ellenörző módszer legfeljebb véltelen foghatta volna meg.

Az ötleteket mindenesetre köszönöm mindenkinek!

UPDATE2: most volt időm kicsit kisérletezni. Nyilván az érintett memóriamodul előbb-utóbb útnak indul a szemetes felé, de előbb megpróbáltam szoftveresen kizárni a hibás memóriaterületet. Erre régen volt a badram/badmem patch, akkoriban egy P1-es gépben még használtam is. Most utánanéztem, mi a korszerű megoldás erre, szerencsére már nem kell kernel patch hozzá. A grub2 ki tudja zárni az érintett területet a BIOS e820 memory range-ek módosításával (egészen pontosan nem egy reserved range-et vesz fel - ahogy elsőre gondolnám - hanem a usable range-et bontja két részre és kihagyja a lyukat). Így elvileg bármilyen e820-at tiszteletben tartó oprendszer számára hatásos lesz a kizárás. Megjegyzem emiatt a memtest86-ra is hatni fog, de legalább könnyu kipróbálni, hogy jó lett-e.

/etc/default/grub-ba

GRUB_BADRAM="0x001bbca317c,0xffffffffff0"

Figyelem, ne higgyünk a memtest86 Badram Addresses kijelzési módnak, az levágja a címet 32 bitre. Ettől még könnyen lehet hogy jó lesz, mert a maszkot is levágja, csak szűkségtelenül zárunk ki több területet.

sudo grub-mkconfig -o /boot/grub/grub.cfg

Annyi történt, hogy a /boot/grub/grub.cfg header részbe (tehát nem a konkrét boot entry-khez) bekerült ez

badram 0x001bbca317c,0xffffffffff0

Reboot.

Először is memtest86, ezuttal szigorúan 4.0a.

Ja igen, ha nem lenne meg, mert a grub-mkconfig alapból nem generálja, akkor

sudo cp /etc/grub.d/20_memtest86+ /etc/grub.d/42_memtest86_custom

majd a 42_memtest86_custom scriptben a MEMTEST86_IMAGE= változót átírni ahová a memtest86-4.0a.bin került.

A memtest86 ezúttal hibátlanul viszi az összes tesztet. Ez egyrészt jó, mert jól kihagytuk a hibás részt, de rossz is, mert a memtest-et nem azért tartja az ember, hogy ne találja meg a hibákat. Elvileg erre is van megoldás (még nem próbáltam), a badram 0x001bbca317c,0xffffffffff0 sort a headerből a menuentry alá kéne tenni, és akkor csak az adott entry-re érvényes. Ehhez viszont a grub-mkconfig-ot némileg át kéne szabni, ezt egyelőre nem csináltam meg.

Jöhet a rendes boot. dmesg-ben a következő memory map figyel:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bff8ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000bff90000-0x00000000bff9dfff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000bff9e000-0x00000000bffdffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000bffe0000-0x00000000bfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001bbca2fff] usable
[    0.000000] BIOS-e820: [mem 0x00000001bbca3400-0x000000023fffffff] usable

Látható, hogy a 0x1bbca3000-0x1bbca33ff tartomány ki van hagyva. Furcsa, hogy miért pont 1024 byte, én egy egész 4k-s page-re számítottam volna.

Végül a teljesség kedvéért a diszk írási teszt is megismétlésre került, és ezúttal teljesen hibátlan!

A memóriamodulban ettől azért még nem bízom, előbb-utóbb repülni fog a gépből. Egy reinstall vagy bármi más kisérletezés után igen könnyen elfelejtődhet, hogy a hibás tartományt ki kell hagyni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

OFF: Mi indított arra, hogy ilyen speciális tesztet végezz? Sérült fájlokat fedeztél fel az SSD-n vagy alapjáraton ennyire óvatosan veszel bírtokba egy új adathordozót? :) Egyébként le a kalappal, dúrván nyomod :)

A 3 nap visszavásárlási garancia indított rá. :) Alapvetően az SSD-vel szemben voltam bizalmatlan, kicsit sokba került biztosra akartam menni.

Sajnos korábban a HDD-kel szemben nem voltam ennyire paranoid, azokat csak /dev/zero-val szoktam teleírni (elsősorban mechanikai vagy valami durva felülethibát feltételezve). Az SSD-k ennél rafináltabbak belül, azoknál könnyen előfordulhat, hogy ha csupa 0-val írom tele, akkor a firmware trükkösen kioptimalizálja az egészet.

Lehet, hogy az alaplapom hibája kijött volna jóval hamarabb, ha a HDD-knél is így csinálom.

Egyébként utólag belegondolva volt előjele. Amikor btrfs-sel kisérleteztem, kb 1,5 óra (tegyük hozzá, igen durva, de rendeltetésszerű) használat után elkezdett a kernel inode error-okat dobálni a logba. Na ekkor írtam le a btrfs-t magamnak. Most belegondolva, lehet, hogy ártatlan volt...

Az a rossz, hogy ~1 TB adatom van, amit üzemszerűen ezzel a géppel használtam. A backupot (már amiről van) is ezzel csináltam. Ebbe most így jobb nem belegondolni... :(
---
Internet Memetikai Tanszék

OFF2: a téma indító kérdésére nem tudom a választ, de hasznosítani szeretném az ellenőrzési módszert.

Teleírás "random" (de mindig reprodukálhatóan azonos) adattal:

dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample | sudo dd of=/dev/sdb bs=8192

Visszaellenőrzés:

dd if=/dev/zero bs=8192 count=31257387 | openssl enc -rc4 -nosalt -pass pass:sample | sudo cmp -l - /dev/sdb

Kérdésem, hogy a blokkok számát (31257387) hogyan határoztad meg?
A blokkméretnek mi a jelentősége (8192)?

Számításom szerint az SSD 256GByte méretű lehet (8192x31257387=256060514304).

Így határoztam meg:

SIZE=$(sudo hdparm -I /dev/sdb | grep 'LBA48 user addressable sectors' | cut -d':' -f 2)

Ezután megnéztem, hogy melyik legnagyobb 2 hatvány esetén kapok még egész blokkszámot, ez 8192 lett. Arra játszottam, hogy minél nagyobb blokkméret legyen, hogy kevésbé egye a CPU-t. De 4096 is simán jó lehet. Sőt igazából nincs sok jelentősége, mert nem O_DIRECT-tel írok. Akkor pedig a block layer merge-öli az egymást követő műveleteket.

---
Internet Memetikai Tanszék

Köszönöm a gyors választ, sokat tanultam belőle.
(Eddig is használtam a dd-t, főleg pendrive-ok és memóriakártyák klónozására, mentésére, ellenőrzésére, nagyon jó hasznát vettem. Most új felhasználást nyer nálam.)

dcfldd látványosabb, és ugyanezeket tudja, dd helyett scak azt használom.

Azért nem szeretem az ilyeneket, mert amikor tényleg kell, akkor pont nem lesz ott. A sima dd még busyboxban is van (még ha nem is tud mindent, amit a teljes). De akármilyen pendrive-os, pxeboot-os live valamiről indítva a sima dd mindig meglesz, a dcfldd pedig nem.

Hasonló okból voltam kénytelen a vi-ra is rászokni (vagy legalábbis az alap commandokat megtanulni benne). A legtöbbb bare-minimum rendszertelepítés után kb ez az egyetlen editor. Innen kell előbb hálózatot konfigolni (rossz esetben proxy beállítással súlyosbítva), majd repokat/mirrorokat konfigolni, na és csak ezután lehet {yum,apt-get} install {mcedit,joe,nano, emacs,vim,whatever}
---
Internet Memetikai Tanszék

ACHI-t írtál AHCI helyett. :D

Komolyra fordítva: Ha nem megoldható az alaplapcsere (nem flamewart akarok indítani, de én évek óta csak Intel gyártmányú alaplapot veszek és adok el Ügyfeleimnek, mert meguntam a szopást a többi "márkával"), akkor BIOS frissítés, -esetleg Downgrade, ha nincs frissebb és engedi- és az SSD-ben is firmware frissítés, amit elsőre kipróbálnék.

Mennyire melegszik a déli híd? Lehet, hogy ha kapna egy jó érintkező hűtőbordást ventilátorral, akkor meghálálná, bár ezt kétlem, hogy 100%-osan megoldaná a problémádat.
Szerintem simán szar az alaplap.
Az IDE portból azt feltételezem, hogy jópár éves lehet.
Majd a többiek jönnek a tápcserével, meg a kondikkal, az is megérhet egy kört...


openSUSE 12.2, vagy ami éppen jön.

- ACHI -> kösz, mindjárt fixálom
- SSD-ben firmware friss (és nem downgrade-elném, mert olyan hibát javít, amit nem szeretnék látni)
- Alaplap BIOS valóban nem a legfrissebb (changelog alapján nincs ehhez kötődő javítás - de persze ezek sunyik nem feltétlen kötik a vevő orrára). Ez még hátra van.
- Táp - ezt elfelejtettem írni, FSP 350GLN, és a feszültségek rendben vannak, ripple az 5V-os ágon 50mV alatt. A 12V-on ripple-t nem mértem ki Eredetileg az SSD tápellátására gyanakodtam, az meg csak 5V-ot vesz fel. SATA tápkábel csere is volt, nincs semmi hatása.
- A déli híd nagyon melegszik, de ezt kb minden ICH8-9-10-nél így van. Adatlap szerint 100C-ig jó, ez 60-70C lehetett. (Erről azért megvan a saját véleményem és nem akarom nagyon leírni, mert csúnya) Mint írtam, már kapott is ventilátort, ami kicsit segített, de nem eleget. Az északi híd is kapott ventilátort már régen (gyárilag ez sem volt, de muszáj volt, mert a szó szoros értlemében forrt), viszont most 5V-ról felvettem full fordulatra azt is.
- 2009-es az alaplap, gari persze már nincs rá. Ha cserélni kell, akkor sajnos megy vele a CPU, és a RAM is. LGA775-ös alaplapból már csak nagyon legalját lehet kapni, annak nem látom értelmét.

A probléma egyébként nem is az, hogy ezt a konkrét esetet hogyan kezelem, hanem hogy paranoiássá tett. Ok, hogy olvas az ember meséket az undetected error-okról a zfs meg btrfs checksumok kapcsán, de élőben találkozni vele elég rossz élmény. Éveken keresztül tud lappangani egy ilyen hiba jelzés nélkül, csak éppen pusztítja az adatotkat. Egyszerűen ennyire nem lehet bízni ezekben a cuccokban és ez baj. Erre kéne valami megoldás, ami OS szinten ellenőrzi a block device integritást.
---
Internet Memetikai Tanszék

A válasz benne van a hozzászólásodban: használj checksumos filerendszert (bár ezek mintha csak a metaadatot checksumolják, nem az összes adatot)

Azt jó volna még tudni, hogy vajon tudod-e ezt a hibát reprodukálni hdd-vel is. Nekem az a sejtésem, hogy egy olyan sunyi hibát fedezhettél fel, ami csak az SSD-vel kihajtva jön elő. 2009-ben még közel sem voltak ilyen gyors SSD-k...

Sajnos időközben már van válasz rá. HDD-vel is jön, csak ritkábban.

A checksumos fájlrendszerrel az a baj, hogy az eső után köpönyeg, csak akkor dobja ki, amikor vissza akarom olvasni. Akkor meg már bőven késő. Valaminek triggerelnie kell, hogy azonnal legyen visszaolvasás.

De ha belegondolok, hogy Fedora 17-tel kisérletezve a btrfs a maga szuper checksumjával milyen csúnyán összf**ta magát... és semmi nem utalt arra, hogy ez a block device hibája lenne, hanem mindenféle invalid inode hibák jöttek, mintha a btrfs saját jogon lenne szar.
---
Internet Memetikai Tanszék

Valaminek triggerelnie kell, hogy azonnal legyen visszaolvasás.

Mintha a ZFS-nek lenne ilyen "írás után ellenőrizzük vissza" c. megoldása. Anno pl. a Netware 3.11 biztosan tudott már ilyet, lassan ideje, hogy a mai fiúk is felfejlődjenek :D

hogy Fedora 17-tel kisérletezve a btrfs a maga szuper checksumjával milyen csúnyán összf**ta magát...

Szerintem meg szimplán egy experimental fájlrendszerrel szopattad magadat. Nincs ebben semmi meglepő, sokezer alfa/bétateszter tesz ugyanígy.

Szerintem meg szimplán egy experimental fájlrendszerrel szopattad magadat
:) Pont az volt a cél, hogy megállapítsam, hogy a btrfs rossz-e vagy nemjó. 1,5 óra alatt kiderült :), bár ez a data corruption bug is rásegíthetett.
---
Internet Memetikai Tanszék

Csak az alaplapnál gondoltam az esetleges BIOS downgrade-re, az SSD-knél én is mindig a legfrissebb fw-t használom.
De mint mondtad is, az épp nem a legfrissebb, úgyhogy megért a cserére.
Sok olyan hibát is szoktak javítani, ami a changelogban nincs benne, de gondolom ez senki számára nem meglepő. :)

Persze, hogy az Intel gyártmányú Intel chipes Intel alaplapo közt is van hibás. Nem is állíthatja senki, hogy bármely gyártó hibátlan termékekkel áll elő mindig.
Én viszont azt tapasztaltam, hogy kb. 6-7 éve, mióta csak Intel alaplapokat árulok és használok, nem kell a szervizekben laknom és folyamatosan szívnom valami (számomra) megmagyarázhatatlan hibával, mint előtte.
Sok olyan gépben cseréltem annakidején alaplapot, aminél csak azt a magyarázatot tudtam adni Üf.-nek a hébe-hóba jelentkező hibákra, hogy ABIT az alaplap.
Utána jöttek az MSI-s gépek, amik szintén egy alaplapcserétől egycsapásra megjavultak.
Szívtam ASROCK-al, ASUS-al, Gigabyte-al... szinte mindennel.
Magasan a legkevesebb hibaaránya és a legjobb szervize az Intelnek van.

Pl. volt egy hibás Intel alaplapom.
Az Intel honlapján a webes felületen bejelentettem, hogy hibás a termék.
Másnap! jött a futár, hozott egy új alaplapot és ha már ott volt, egyúttal elvitte a rosszat is.
Nem nekem kellett Pestre mászkálni, az unott képű szervizesekkel hadakozni, magyarázkodni, otthagyni, 1 hetet várni, telefonon érdeklődni, kapcsolásra várni és 11 órakor megvárni, míg a keresett illetékes megebédel, másnap újra érdeklődni (itt egy 3-7 napos iteráció jön), majd újra felmenni érte Pestre és átvenni az új alaplapot.
Közben én ezt nem teszem meg az Ügyfeleimmel, már mánap adtam és ingyen beszereltem egy újat sűrű elnézéskérés közepette, adatot mentettem, ingyen telepítettem, adatot visszaállítottam, stb...

Számomra az Intel tisztább, szárazabb érzés.


openSUSE 12.2, vagy ami éppen jön.

Sajnos ezek az előnyök központi közbeszerzés esetén nem jönnek ki. Márpedig az egyetem sajnos erre kötelezett hely volt, és mindegy volt, hogy mit vettél, csak ugyanattól a két cégtől lehetett, ugyanolyan garanciális ügyintézés mellett. Mondjuk a garanciával nem voltak nagy bajok, azon túl hogy általában sokat ültek rajta.

Egyébként persze volt Intel alaplapom is, csak azt a hugomnak odaadtam. :) Mivel a másik SSD oda megy, ezért az jól is teszi, ha továbbra is hibátlanul működik.

A gond inkább az, hogy az Intelnek is vannak 15-20eFt-os low-end alaplapjai, és azok szerintem nem sokkal jobbak egy akármelyik taiwaninál. Feture-wise ezek nekem amúgy megfelelnének, semmi szükségem a tuningos extrákra. Inkább a magasabb ártartományban lehet különbség, ott a taiwaniak a hülye vérpisti feature-ökre mennek rá, az Intel meg talán inkább a minőségbiztosításra.
---
Internet Memetikai Tanszék

Ja amúgy Intel alaplapom is szállt már el (még amikor az egyetemen dolgoztam - persze hol máshol, mint a backup szerverben), szóval az sem mind arany. Ja és ott is emlékszem, hogy valami P2-es hűtőről kellett leoperálnom ventilátort a déli hídra, mert nem bírtam elnézni, hogy 70C felett van.
---
Internet Memetikai Tanszék

"- SSD cserélgetés nem vátloztat (olyan HDD most nincs kéznél, amiről törölhető minden)"
Naív kérdés:
- akkor most más SSD-vel csinálja, vagy nem?
- baromira érdekelne mégis, hogy akkor egy hagyományos HDD-vel csinálja-e vagy sem?

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Fentebb írta, hogy HDD-vel is megvan a hiba, csak valamivel kisebb lambdával jönnek a hibák.

LGA775-el jártam már úgy, hogy dual channelbe tettem különböző típusú DIMM-eket amik aztán DMA-nál hibáztak, de a memtest nem mutatta ki. Ha van dual channeled, bontsd szét vagy próbáld ki 1 modullal.

Szoftveres adatintegritás csekk csak btrfs-ben van. http://neil.brown.name/blog/20110227114201

Egy próbát végülis megér...
---
Internet Memetikai Tanszék

Pont előttem írták, de ha már végigolvastam az indítót leírom én is: futtass rajta egy memóriatesztet a memtest86 4.0a multithreaded verziójával. Tizenvalahány ciklus elég lesz.

95% hogy a memória körül kell keresni a gondot, 5% a chipset. Lehet rossz modul, vagy apró kompatibilitásprobléma.

+1

Kösz, ránézek. A multithreadred memtest86 eddig elkerülte a figyelmemet.
---
Internet Memetikai Tanszék

És itt a megoldás!

0x001bbca317c címen 00000080-s maszkkal hiba van. Ha jó irányból nézem a little endian-t, ez azt jelenti, hogy 0x001bbca317d címen lévő byte legfelső bitje a hibás, ami tökéletesen megmagyarázza, hogy miért mindig 0x17d-re végződik a hiba címe. A 12 bit pont egy page, csodálkozom, hogy ez idáig nem ütött szöget a fejembe.

Ami viszont tényleg döbbenet, hogy a sima memtest86 ebből semmit nem lát, csak a 4.0a-ból a parallel tesztek fogják ki, azok viszont kökeményen (egy teljes futás után ~70 találat lett erre a címre).

Innentől kezdve az integritás-ellenőrzési kérdés kicsit okafogyottá vált, mert erre a fajta hibára ECC-s memória való, itt más megoldás nem segített volna.
---
Internet Memetikai Tanszék

Öröm, bódottá! :)


openSUSE 12.2, vagy ami éppen jön.

És megnéznéd másik RAM-mal is? Illetve melyik teszt fogta meg? Azt írja, hogy a 7-es tesztnél jön ki leginkább a sávszélességgel kapcsolatos hiba, ami új a korábbi memtesthez képest.

Fentebb írta valaki a dual channelt, az is érdekelne, hogy vajon az okozta-e.

Nekem is volt hasonló hibám fél éve, de nem sikerült rábizonyítani, ezért RAM és alaplap is ment a kukába. Ha még meglenne, szívesen letesztelném újra.

Érdekelne, hogy pontosan mi okoz ilyen hibát, a helyedben még nyomoznék kicsit :).

--

Az összes parallel teszt megfogta, viszont semelyik sequential. Ez nekem egy teljesen fix bithibának néz ki, még csak nem is bizonytalankodik, teljsen következetesen akármelyik parallel teszt azonnal beletalál. Nem tudom, hogy pontosan mi rejti el a hibát single CPU esetben (L1 cache nem invalidálódik? Az L2 cache a két magnak közös, az még ugyanúgy elrejtheti parallel esetben is.). Nem teljesen világos az sem, hogy a block deivce-on lévő bithiba előfordulási arány miért reagált valamelyest az ICH hőmérsékletre. 3db 8cm-es ventilátor hűti most az alaplapot, ebből nyilván a memória is kap bőven huzatot. Talán csak annyi, hogy vannak olyan bitminták, aminél határeset, hogy kijön-e, ilyenkor számíthat a hőmérséklet. Viszont a memtest86 jellemzően pont nem ilyenekkel tesztel.
---
Internet Memetikai Tanszék

Lehet, nagyon álmos vagyok, de nem értem, hogyan jött ki, hogy éppen azon a címen van a hiba, ahol vártad. Ha a 0x001bbca317c címen van aabbccdd, akkor kis indiánnál nem így néz ki a dolog?

0x001bbca317c: dd
0x001bbca317d: cc
0x001bbca317e: bb
0x001bbca317f: aa

Ebből nekem az jönne, hogy 0x001bbca317c címen volt 0x80 maszkkal a hiba, nem pedig eggyel feljebb. Mivel írtad, hogy figyeltél erre, így nyilván én tévedek, csak nem értem, hol. Valami nagyon elkerülte a figyelmem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van abban valami, amit mondasz, tényleg a legalsó byte-on van az. Már ha tényleg jól gondolom és ez nem valami idióta mixed endian kijelzés. Én öszintén szólva megelégedtem azzal, hogy abban 32bits szóban van. Vannak furcsaságok még. Eleve a 64bites címkezelés a memtest86-nak nem erőssége. A kirásban ez szerepel: 0x001bbca317c. Err bits: 00000080. Miért pont 44bites a cím? A 48 bitet tudnám hova tenni, a 40 bitet is. Viszont ha badram address kijelzésre kapcsolok, akkor ezt írja: 0xbbca317c,0xfffffffc, itt faszán lecsapta 32 bitre a címet.
---
Internet Memetikai Tanszék

off:Azt nem tudjátok hogy Sandy Bridges procival miért nem megy se 4.0a se 4.0b verzió,míg 3.5b elindul?Bebootol majd nem történik semmi nem jelenik meg csík és nem is reagál onnantól semmire.

imádom a hupot!

+1

Gratula a kitartásért. Tanulságos.
Ezek alapján felvetődik a kérdés, hogy melyik memóriatesztelő szoftvert célszerű használni a jövőben?

+1

Ma is tanultam valamit.
Már az sem mindegy, hogy milyen memória tesztelővel tesztelünk...
Bár már öt éve sem tudtam meggyőzni az amerikai rendszergazdát, hogy memória-hibás a folyton fagyogató Dell gép, mert a Dell gyári memória tesztere szerinte jónak találta...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

+1

Hasonló helyzetben nekem úgy sikerült, hogy átraktam egy ugyanolyan gépbe és ott is produkálta a fagyást. Igaz, nem amerikai volt.

Ez egy gyönyörű hibakeresés, tesztelés volt.
Gratula!
(UP: még jól jöhet később...)

+1

Ez engem annyiból érdekelne, hogy van pár gép beépítve, elérhetetlen helyen, amin memtestet kéne végrehajtani, de monitort nem lehetséges rájuk kötni. Van olyan teszt, ami automatikusan el tud indulni mondjuk pendrive-ról, és log fájlba tud írni (pendrive bootsorrendben legelöl van, ssh van az újraindításhoz)?

Nekem volt egy érdekes fájlrendszersérülésem pár hónapja. Akkor nekem sem bukott meg a memtesten. Azóta volt baj nfs felett másolt fájlokkal is, de azt próbáltam a tcp gyenge hibadetekciós képességére kenni (az nfsv3-hoz nem értek, nem tudom, hogy csinál-e valamilyen hibaellenőrzést).
Most viszont, a topicból szerzett információk alapján, csak úgy simán Linux alatt elindítottam 3db memtester példányt, mindegyikhez a fizikai memória kb. 1/4-ét rendelve. Dobálták is a hibákat, míg le nem állítottam őket. Persze egy példányban egy napig is elvan bármiféle hibajelzés nélkül. Erről ennyit, "remélem" nem a memória, hanem az alaplap lesz szar.

Köszönöm, megpróbálom első körben ezt a megoldást.

Olyanról tudok, hogy memtest86 serial console-ra adja a kimenetet. Ez a command line kell hozzá (példa GRUB2 formátumban):

linux16	/memtest86+.bin console=ttyS0,115200n8

Ha valami brand szerverről van szó, akkor azon lehet BMC-ből serial over lan-t csinálni, majd ipmitool-lal kapcsolódni hozzá. Mondjuk a BMC első konfigolásához kelleni fog monitor...
---
Internet Memetikai Tanszék

Köszönöm, ez a command még hasznos lesz.

Mondjuk a BMC első konfigolásához kelleni fog monitor...

Rendes szerveren nem. Azon van soros konzol, ahol egy külön kis Linuxos mikrokontroller lakik, aki akkor is aktív, amikor a gép éppen ki van kapcsolva.

Arra gondoltam, hogy legalább a BMC IP címet egyszer be kell állítani neki, ha még nem volt használatba véve. (Bár volt már olyan, hogy defaultból DHCP-re volt rakva én meg arp-ből MAC cím tippeléssel lőttem be, hogy melyik IP-n melyik gép BMC-je van, de ez mondjuk gányolás). A kérdés alapján nem hiszem, hogy full-blown külső soros konzol aggregátor lenne kiépítve a helyszínen, ha egyszer sima IP konzol sincs. Őszinte legyek, a kérdésfeltevés alapján még a brand szerver sem valószínű (pl ECC felmerült volna, ha az). Bár ha esetleg vPro-s desktop alaplap van, akkor azon is van BMC, csak az nem IPMI-vel megy.
---
Internet Memetikai Tanszék

Persze, hogy be kell állítani. Amikor a gépet berakod a rackbe, beledugod a 220-at, na akkor rádugsz egy soros terminált, és adsz neki menedzsment IP címet. Utána bedugod a hálózatba a menedzsment Ethernet portot meg a gép rendes Ethernet portját, és távozol a helyszínről. Telepíteni lehet távolról is.

én általában megúsztam a monitort és a serialt is :) wireshark remekül tud ip-t gyűjteni :) újabbak már ipv6-on is elérhetőek :) ( ...vagy csak azon :) )

subscribe

+1

+1

+1

+1

.

bookmark :)

+subs
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Köszi az update-eket :) Szép munka :)

LOL 6 éves topik
--

Nem beszelve arrol, hogy ennyi idot beleolni egy ilyen problemaba nem igazan eri meg. Peldaul ha barmi hasonlo jelentkezik, akkor:
1. masik gepben drive vizsgalat
2. live OS-el ellenorzes
3. minimal RAM (1 modul) + 1x csere masikra inditas
4. valoszinuleg alaplap hiba..

Szerintem az ilyen típusú tudás a szükséges komolyabb -nem szalagmunka IT support- beosztásba, ahol már nem lehet azzal elintézni egy fél földrészt jelentő Azure kiesést h. hát cseréljünk ki minden szervert az összes datacenterben, oszt talán akkor 1 hét múlva nem ismétlődik meg a gikszer.
Ez a blogposzt pl. teljesen jó felvételi ajánló v. referencia lenne bármilyen forensic állásra.
--

Óbzmg... ezt nem vettem észre, pedig napok óta olvasgatom... áááá... :DD
(...és most ezzel én is felhozom...)
<-------
You can't grep on dead trees.

Sosem árt újra átnézni. Ismétlés a tudás anyja :)

[Feliratkozás]