Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Things Repairer 08. 03. 2026, 08:48:54
-
Párkrát se mi stalo, že počítač při velké zátěži padal a ačkoliv memtest i při velmi dlouhém běhu vždy prošel, vždycky se nakonec postupným vyndaváním našel modul, který to způsoboval.
Předpokládám, že vadná RAM mívá vyšší chybovost s vyšší teplotou, a memtest86 prostě nevytíží hardware natolik, aby se to začalo projevovat.
Existuje nějaká alternativa memtest86, která vytíží cpu a ideálně i igpu, případně lze reálně nějak testovat RAM z OS, aby při tom šlo paralelně pustit libovolný stress test?
-
Pred mnoha miliony let jsem ten samy problem resil zakoupenim fenu na vlasy a teplomeru (abych nedostal pameti mimo rozsah pracovnich telot). Slo to docela rychle.
-
z OS jde RAM testovat pomocí memtester, ten ale nedělá téměř žádnou zátěž a testovanou paměť si zamkne pro sebe
se zátěží je tu mprime torture test, paměť nejvíce zatíží Large FFTs: https://www.mersenne.org/download/
nebo linpack/xhpl, tam nastavit, aby velikost problému zaplnila skoro celou RAM a pak to testuje i paměť v zátěži: https://www.root.cz/clanky/high-performance-linpack-hpl-prakticky-kompilujeme-a-testujeme/
-
počítač při velké zátěži padal a ačkoliv memtest i při velmi dlouhém běhu vždy prošel
A jaký to máte procesor? V práci jsme řešili podobné problémy u Intel 13600 a technik říkal, že těch problémů s Intelem je hodně. Měnily se i Intel 14700 a některý i dvakrát.
-
A jaký to máte procesor? V práci jsme řešili podobné problémy u Intel 13600 a technik říkal, že těch problémů s Intelem je hodně. Měnily se i Intel 14700 a některý i dvakrát.
Zažil jsem to dvakrát ve dvou různých desktopech s AMD Phenom II, jednou laptop i5 3. generace a teď aktuálně i5-8250u.
Považuji za nepravděpodobné, že by za to mohl cpu, když se vždy našel jeden modul, jehož vyndáním/nahrazením se problém odstranil.
-
Memtest86 beriem skôr ako základ. Tiež som už zažil RAM, ktorá prešla memtestom cez noc a potom PC padal až pri normálnej záťaži alebo pri hrách. Ja by som to skúšal priamo vo Windows. TestMem5 s nejakým prísnejším profilom, prípadne HCI MemTest, a popri tom pustiť niečo, čo zohreje CPU a pamäťový radič. Napríklad OCCT CPU plus RAM alebo y-cruncher. Ak máš iGPU, tak kľudne zaťažiť aj tú, lebo si berie pamäť zo systému a vie to chybu vytiahnuť skôr. Ešte by som sledoval WHEA chyby v Event Vieweri. A určite by som skúsil aj bez XMP/EXPO. Ak to padá len so zapnutým profilom, nemusí byť hneď zlá RAM, môže to byť pamäťový radič, doska alebo len zlé nastavenie. Ak to padá aj na default, potom by som už testoval moduly po jednom a v rôznych slotoch. Za mňa najlepšia kombinácia je RAM test v OS plus paralelne záťaž CPU. Samotný memtest86 vie niekedy prejsť a aj tak je zostava v reálnom používaní nestabilná ;)
-
Pokud je tím OS Windows, ten má v sobě taky nějaký memtest a dokáže mu nastavovat i nějakou obtížnost, ale je to MS, takže je to relativně BFU-friendly, což není vždy úplně žádoucí. Beru ho jako alternativu (druhá ruka) k memtestu, že jako když je to jeho test a projde to, tak ať si pak Wokna nestěžujou ;).
Jinak souhlas s tím, že MemTest jako takový nemusí být vždy dostačující, protože kolikrát je lepší tomu dát zaprdět tak, aby se i zdroj ukázal, jak moc je v pohodě. ZAtím jsem se naštěstí snad ve všech případech (výjimky si snad ani nevybavuju) setkal s tím, že když je RAMka skutečně vadná, MemTest to rovnou odhalí. Spíš jsem se setkal s false-positive u některých verzí MemTestu se zapnutým SMT, než že by prošla paměť, která vadná skutečně je.
-
Na Win jde naplánovat mem test na příští reboot přes MdSched.exe
Testy se zapnutou cache doběhnou rychle a nic nenajdou, u testů s vypnutou cache jsem se nikdy nedočkal výsledku.
Nevím jestli memtest86 spolehlivě rozpozná chybu u ECC pamětí nebo to HW zamaskuje.
-
počítač při velké zátěži padal a ačkoliv memtest i při velmi dlouhém běhu vždy prošel
A jaký to máte procesor? V práci jsme řešili podobné problémy u Intel 13600 a technik říkal, že těch problémů s Intelem je hodně. Měnily se i Intel 14700 a některý i dvakrát.
CPU Intel 13. a 14. generace měly známý problém přímo v CPU, s tím RAM nemá nic společného.
-
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 (https://forum.root.cz/index.php?topic=30523.msg420889), 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.
-
ECC je ještě speciální kapitola. Memtest86 i Memtest86+ tuším dnes oba umějí přečíst chyby RAM. Ale nebylo tomu tak vždy, tuším. Jenže pak tu jsou některé Ryzeny, které sice umějí opravovat chyby, ale neumějí je reportovat. Což testování moc nepomůže.
-
2) pustit GLSL brnchmark(vybranà scéna) /video render . pak v hwmonitorr vidiß kolik wwattů(až3w) a kolik gbps(až30) teče
My rramky dosahuju 70až75 po 15min běhu. Stabilní sou , jen se ptám zda to může. Postupně poškozovat. (A zda to že v hwinfo32 mají jakýsi flag extended temperature range až 85. Má váhu nebo bezcenný flag) . příčina je dementní návrh layoutu komponent: 2 so-dimm nad sebou .
-
Párkrát se mi stalo, že počítač při velké zátěži padal a ačkoliv memtest i při velmi dlouhém běhu vždy prošel, vždycky se nakonec postupným vyndaváním našel modul, který to způsoboval.
Předpokládám, že vadná RAM mívá vyšší chybovost s vyšší teplotou, a memtest86 prostě nevytíží hardware natolik, aby se to začalo projevovat.
Existuje nějaká alternativa memtest86, která vytíží cpu a ideálně i igpu, případně lze reálně nějak testovat RAM z OS, aby při tom šlo paralelně pustit libovolný stress test?
Jo, tohle je reálný scénář. MemTest86 sice umí RAM pořádně prověřit, ale zátěž celého systému je přece jen jiná než při současném vytížení CPU/GPU a zahřátí skříně.
Já bych zkusil testovat RAM přímo z OS, třeba TestMem5 s agresivnější konfigurací, případně Karhu RAM Test. K tomu můžeš paralelně pustit CPU stress test typu OCCT nebo Prime95. Tím dostaneš RAM pod zátěž a zároveň ji pořádně tepelně zatížíš.
U integrované grafiky je to ještě zajímavější, protože si bere systémovou RAM. Tam bych pustil GPU test současně s RAM testem a sledoval teploty. Pokud se chyba objeví až v této kombinaci, je to docela dobrá stopa.
-
Kdysi mi padal počítač občas u suspend - normálně ne, i když jsem jednou (!) objevil chybu při kopírování z externího disku. memtest86 našel block 16 kB s pár chybama, tak jsem jej vyřadil přes kernel option.
Na suspend padá občas nadále, tak nevím, jestli je paměť při udržovacím příkonu náchylněší. Vtipné je, že jsem pak memtest86 zkoušel znovu, aby našel nové chyby - a nenašel ani ty staré.
TestMem5 se podívám. memtest přímo ze systému našel chyby taky, ale nepřeložil je na fyzickou adresu, takže celkem k ničemu. TestMem5 to umí?
-
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.
-
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.
-
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 (https://forum.root.cz/index.php?topic=30523.msg420889), 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.
-
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:
# 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:
#define PCI_DEVICE_ID_INTEL_IE31200_HB_CFL_10 0x3ecahttps://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.
-
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.
-
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.)?
-
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