Jak odhalit vadnou RAM?

[Martin Poljak]

A není jednodušší tu vadnou RAM, když už Memtest našel chyby, vyměnit za novou (ne-vadnou)?
Je pěkný že jde softwarově omezit že nějakou část modulu nemá systém používat ale sorry jako - provozovat vadnej hardware je nesmysl.

Co je smysl a nesmysl se tak trochu posunulo od té doby, co začal tenhle AI blázinec a paměti zdražily mnohonásobně. Když jsem si těsně před zdražením stavěl pracovní desktop, fakt mě nenapadlo, že za půl roku ty paměti, co v něm mám budou stát tolik, co celý zbytek toho počítače dohromady. Pak logicky uvažujete o dost víc co provozovat a co nahradit.

Na druhou stranu přesně v tomhle případě bych byl víc než opatrný i kdyby měl ten modul jenom vyhodit. Kdyby ta paměť systematicky chybovala v jednom regionu, bylo by to mnohem lepší než to, co popisoval (což ovšem nebyl originální tazatel). To, že vypadává náhodně znamená, že může vypadávat náhodně kdekoliv což znamená, že nejenže systém může tuhnout, to by bylo ten nejlepší případ, ale může vracet chybná data třeba v page cache. Což -- pokud to nedělá masivně -- není zprvu poznat. To člověk zjistí až po nějaké době, když najednou zjistí, že má poškozenou polovinu filesystému protože RAM při zápisu na disk nevrátila to, co bylo do page cache původně zapsáno ale někde flipla nějaké bity. U mně celkem nedávno trvalo měsíc, než jsem to zdetekoval a data jsem zachránil tak tak díky inkrementálním zálohám.

[Reklama]

[František Ryšánek]

Nevím jestli memtest86 spolehlivě rozpozná chybu u ECC pamětí nebo to HW zamaskuje.

Měl jsem tu zkušenost, že zamaskoval. DDR4 ECC, ve Windows serveru v logu spousta zmínek o ECC chybách, stroj citelně pomalý, MemTest zelený PASS. Po výměně RAM vše OK.

Do záznamu bych rád zmínil klíčové slovo EDAC. V Linuxu se vyskytuje v dmesg, pokud máte moderní hardware s podporou ECC a natažený příslušný driver v kernelu. EDAC zde znamená dohledové hardwarové rozhraní DRAM kontroléru se schopností ECC. Bez googlení nevím, zda to vykvete na PCI-e, nebo se na to dá sáhnout třeba přes MSR. Každopádně drivery pro to jsou (vedle Linuxu zřejmě i pro Windows, jak píše WIFT) a když řadič DRAM registruje/opravuje ECC chyby, začnou o tom chodit hlášky do systémového logu.

[RDa]

Bez googlení nevím, zda to vykvete na PCI-e, nebo se na to dá sáhnout třeba přes MSR.

Je to mapovano pres PCIe - zcela prvni "device" urci platformu:

Kód [Vybrat] Rozbalit

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3eca] (rev 07)


a pak to chytne:

Kód [Vybrat] Rozbalit

#define PCI_DEVICE_ID_INTEL_IE31200_HB_CFL_10   0x3eca
https://github.com/torvalds/linux/blob/master/drivers/edac/ie31200_edac.c

Ale samotne mazani notifikaci u nekterych platforem (raptor lake / RPL-S) vyzaduje pristup do MSR. Proste kockopes.

Nejhorsi na techto technologiich je, ze nevite jaka je politika na pozadi - hlasi se jen uncorrectable 2-bit chyby? protoze mnoho lidi ty 1-bit ECC correctable chyby nevidi v pocitadlech - jsou opraveny a tudiz nezajimave, ackoliv jejich pocet bychom radi znali.

A samotny memtest v tomhle taky nema jasno. Osobne to vidim na potrebu HW memory testeru (na bazi FPGA), ze kdyz to chci opravit tak potrebuji vedet presne kterej cip jede/nejede. PC casto ani nepostne s nejakou vadou.

[kvr kvr]

A není jednodušší tu vadnou RAM, když už Memtest našel chyby, vyměnit za novou (ne-vadnou)?
Je pěkný že jde softwarově omezit že nějakou část modulu nemá systém používat ale sorry jako - provozovat vadnej hardware je nesmysl.

Na druhou stranu přesně v tomhle případě bych byl víc než opatrný i kdyby měl ten modul jenom vyhodit. Kdyby ta paměť systematicky chybovala v jednom regionu, bylo by to mnohem lepší než to, co popisoval (což ovšem nebyl originální tazatel). To, že vypadává náhodně znamená, že může vypadávat náhodně kdekoliv což znamená, že nejenže systém může tuhnout, to by bylo ten nejlepší případ, ale může vracet chybná data třeba v page cache. Což -- pokud to nedělá masivně -- není zprvu poznat. To člověk zjistí až po nějaké době, když najednou zjistí, že má poškozenou polovinu filesystému protože RAM při zápisu na disk nevrátila to, co bylo do page cache původně zapsáno ale někde flipla nějaké bity. U mně celkem nedávno trvalo měsíc, než jsem to zdetekoval a data jsem zachránil tak tak díky inkrementálním zálohám.

Což o to, jak bych ji s radostí vyměnil, i když by to něco stálo (32 GB - to by mě nezruinovalo).  Ale je to notebook se soldered RAM.  Je to domácí počítač, takže případný totální crash není likvidační.

Ty chyby jinak byly během toho testu konsistentní, ne že by se náhodně stěhovaly.  Zreprodukovat je byl problém, nejspíš v důsledku zatížení, možná vnějších teplot atd.  Což samozřejmě znamená, že tam mohly být chyby, které se zrovna neprojevily - a tam by snad mohlo pomoct něco, co ještě přidává thermal load.

[LacconePanda]

Než smažou ten necropost cizím jazykem, tak dodám, že jednotlivé DRAM čipy mají extrémě nízkou tepelnou setrvačnost -  to znamená, že zahřát je z 40 na 80 stupňů a zpět je otázka desítky sekund. (A pasivním heatsinkem to bude) to nebudu o moc rychlejší,

Mimochodem, pájené RAM (nebo LPDDR nebo integrované LunárníLake) , testují se nějak extra důkladně na problémovost? Třeba včetně průbehu testu za vysokých teplot (tedy v podání  Intelu i 113°C, protože se snaží dál mlátit slámů zvyšováním Tj.)?

[Reklama]

[LacconePanda]

Taky by bylo dobré napsat co že to je za paměťový modul... jaké má featury.

Kdyby ta paměť systematicky chybovala v jednom regionu, bylo by to mnohem lepší než to, co popisoval (což ovšem nebyl originální tazatel)...
. U mně celkem nedávno trvalo měsíc, než jsem to zdetekoval a data jsem zachránil tak tak díky inkrementálním zálohám.

Něco podobného se mi u DDR5 stalo.
-vadný region měl konstantní rozpětí (asi 3GB/32GB)
-s teplotou to nesouviselo
-trvalo delší dobu než ke korupci došlo: odhalil to až test memtestu, který  vkládal 5min pauzy v daném běhu . Nebo se to projevilo jen když windowsy běžely 2 hodiny a déle (někdy BSOD , někdy  artefakty při práci s videosoubory )


A mě počítač spokojeně už půl roku-uptime hlásí edac-util -rfull \n mc_:noinfo:all:UE:0