Mittels stress-ng den ECC Arbeitsspeicher RICHTIG belasten?

[jemandanders]

Hallo
Ich möchte die ECC Funktion des Arbeitsspeichers und des Mainboards überprüfen.
Bzw die Meldung an das Betriebssystem ob Fehler auftreten und korrigiert werden.
Hintergrund ist schlicht, das ich frühzeitig Bescheid wissen möchte, wenn Fehler auftreten.

Vorgegangen bin ich wie bei Hardware Canucks beschrieben
https://hardwarecanucks.com/cpu-motherboard/ecc-memory-amds-ryzen-deep-dive/5/

Ich komme aber mit den Optionen von stress-ng nicht so wirklich klar. Es sind einfach zu viele und mir ist nicht ganz klar wie ich mit welchen Optionen den Speiche mal so richtig unter Druck setzen kann, damit "endlich" mal Fehler auftreten und ich die Dokumentation der ECC Funktion überprüfen kann.
Ich brauche also passende Parameter hierfür, oder eine andere Methode.
Ich habe mal ein bisschen herumgesucht und das hier gefunden
https://stackoverflow.com/questions/45317515/stress-ng-ram-testing-commands
Die vorgeschlagene Befehlszeile habe ich schon etwas abgeändert
@X570-I:~$ stress-ng --vm 19 --vm-bytes 95% --vm-method rowhammer --verify -t 10m -v

Ergebnis ist immer:
1@X570-I:~$ edac-util --v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
edac-util: No errors to report.

dmesg gibt folgendes aus:

[ 4.897321] EDAC amd64: Node 0: DRAM ECC enabled.
[ 4.897323] EDAC amd64: F17h_M70h detected (node 0).
[ 4.897357] EDAC MC: UMC0 chip selects:
[ 4.897358] EDAC amd64: MC: 0: 0MB 1: 0MB
[ 4.897359] EDAC amd64: MC: 2: 8192MB 3: 8192MB
[ 4.897362] EDAC MC: UMC1 chip selects:
[ 4.897362] EDAC amd64: MC: 0: 0MB 1: 0MB
[ 4.897363] EDAC amd64: MC: 2: 8192MB 3: 8192MB
[ 4.897364] EDAC amd64: using x8 syndromes.
[ 4.897364] EDAC amd64: MCT channel count: 2
[ 4.897413] EDAC MC0: Giving out device to module amd64_edac controller F17h_M70h: DEV 0000:00:18.3 (INTERRUPT)
[ 4.897420] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[ 4.897421] AMD64 EDAC driver v3.5.0

Die Option rowhammer, welche für mich ja nicht schlecht wäre bringt scheinbar auch nix.

rowhammer
try to force memory corruption using the

rowhammer memory stressor. This fetches​

two 32 bit integers from memory and​

forces a cache flush on the two​

addresses multiple times. This has been​

known to force bit flipping on some​

hardware, especially with lower fre‐​

quency memory refresh cycles.​

​

​

Ich kann mir das einfach nicht vorstellen, das nicht ein einziger Fehler auftreten sollte.
Ich habe meinen Speicher Undervoltet und die Timings sind auch schon so langsam jenseits von Gut und Böse. (15 - 15 - 15) bei 1,1V.
Es werden bis jetzt aber keine Fehler dokumentiert. Eigentlich sollte man doch erwarten, das dann so langsam Fehler auftreten, welche dann auch dokumentiert werden..
Speicher ist der Kingston KSM26ED6/16ME zusammen mit Ryzen 3700x auf Asus Pro WS X570-ACE

Wenn AMD die ECC Funktion nicht richtig implementiert haben sollte, wäre das natürlich auch möglich.
Ich hatte jedoch vor dem Kauf extra bei Asus nachgefragt und diese nochmals bei AMD in Taiwan. Die Auskunft war, das die aktuellen Ryzen 3000 Desktop CPUs die Speicherkorrektur implementiert haben. Nur halt ohne Verifikation. Die normalen APUs dagegen nicht.
Ich hätte ja auch eine Pro CPU gekauft. Nur wo???

Ich bin vorerst mit meinem Latein am Ende und hoffe auf gute Ratschläge.

 

[Masamune2]

Ich kann mir das einfach nicht vorstellen, das nicht ein einziger Fehler auftreten sollte.

Ich weiß nicht wie es beim Betrieb jenseits der Spezifikationen aussieht aber im Normalbetrieb sind Speicherfehler sehr sehr selten. Es kann also sehr gut sein das du schlicht keinen hattest.

Server bringen in der Regel immer ECC mit und die allermeisten laufen Jahre ohne das irgendwas passiert.

 

[jemandanders]

Das ist mir schon klar und ich hoffe ja, das ich in den nächsten Jahren davon verschont bleibe. Am besten auch für immer.
Ich möchte jedoch frühzeitig vom Betriebssystem benachrichtigt werden, wenn welche auftreten und nicht plötzlich einen BSOD mit der Meldung eines unkorrigierbaren Fehlers haben.
Dafür gibts ja die Dokumentation.

 

[madmax2010]

Wenn ein, wie schon gesagt sehr sehr sehr seltener Fehler auftritt und du den sehr unwahrscheinlichen Fall hast das dieser nicht korrigiert werden kann (beispielsweise weil noch mehr sehr Unwahrscheinliche Fehler auftreten), bringt eine Benachrichtigung dir auch nichts mehr.
Der sagt dann nicht : jo, hier ist ein Problem, schau mal drauf. Da sind dann korrupte Daten und dann crasht halt was.
Soweit möglich werden Fehler ohne das du was machen musst protokolliert

 

[jemandanders]

Soweit möglich werden Fehler ohne das du was machen musst protokolliert

Genau. Diese protokollierung möchte ich verifizieren.
Das die ECC Funktion soweit funktionieren sollte, ist soweit erst einmal klar. Ich liebe jedoch keine Überraschungen.

Das ganze nehme ich deshalb auf mich, weil Speicherfehler eben nicht so selten auftreten wie oft behauptet wird.
Ich spreche da aus leidvoller Erfahrung.
Mit dem Rechner wird auch nicht gezockt. Er soll zur Konstruktion verwendet werden.
Bevor ich aber das ganze nicht für mich schlüssig überprüft habe, wird damit nicht gearbeitet.
Im schlimmstmöglichen Fall müsste ich dann halt wieder auf eine andere Plattform wechseln.

 

[vascos]

mit wieviel mhz laufen die speicher mit 15-15-15 1,10volt ?

 

[jemandanders]

Ganz normal. 2666 Mhz.
Ich will die ja nicht schrotten.
Meinst Du ich sollte vielleicht mal ganz Zart den Takt erhöhen?

 

[vascos]

ich frag nur weil du meinst die sollten mal fehler machen.

ich würd einfach noch weniger volt oder niedrigere timings ausprobieren. da wird auch nix kaputt

oder das selbe wie hwcanucks mit 2400 cl14-14-12-11-21

 

[jemandanders]

OK.
Ich mach das dann mal.

 

[vascos]

problem is nur jeder speicher is a bisserl anders im über sowie untertakten und du willst ja eine gerade noch so stabile\nicht stabile gratwanderung erreichen. also langsam an die grenze rantasten.

 

[jemandanders]

@vascos
14er Timings mag er nicht. Da kommt er erst gar nicht mehr hoch. War dann wohl schon eine Grenze.
Kann natürlich auch daran liegen, das ich die anderen Parameter nicht angepasst habe weil ich schlicht keine Ahnung davon habe.
Undervolting mag er dafür umso mehr.
Aber schon sehr, sehr seltsam das man das so weit treiben kann.
Ich hab eben mal noch Prime95 laufen lassen. Da gibts auch noch keine Meldungen.
Entweder sind das Wunder Speicherriegel oder es ist etwas richtig Faul.
Ich mach mal weiter.

Ergänzung (22. Mai 2020)

Jetzt ist genau das passiert, was ich die ganze Zeit befürchtet habe.
Der Rechner ist bei Belastung abgestürzt, ohne die Protokollierung irgendeines Fehlers.
Scheiße!
Damit ist das Thema AMD + ECC für mich gestorben.
MANN!
Die hatten das doch schon mal so gut implementiert. Sogar mit Chipkill.
Und jetzt so etwas.
Ich bin gerade so dermaßen Sauer. 600€ Für CPU + Board für die Tonne.
Ich stell mir doch keinen Epyc hier hin.

 

[lokon]

Die Option rowhammer, welche für mich ja nicht schlecht wäre bringt scheinbar auch nix.

Der Rechner ist bei Belastung abgestürzt, ohne die Protokollierung irgendeines Fehlers.

Vielleicht fehlt eher das praktische Wissen um den Speichercontroller, ECC und Tests.
Systemintegration , Evaluation und Tests sind kompliziert.
Linux bietet auch verschiedenste Debugging-Einstellungen - loggen über serielle Schnittstelle, loglevel ...
Der Stresstest sollte vielleicht direkter laufen ohne die normalen systemd Dienste, shells usw. im Hintergrund, kein dynamischer CPU Takt usw.
stress-ng wird explizit zum finden von Fehlern im Kernel benutzt.

Bei reddit steht ja vermeintlich auch ein erfolgreicher Test mit dem Board

PS:
Im wissenschaftlichen Aufsatz Exploiting correcting codes: On the effectiveness of ecc memory against rowhammer attacks von 2019 steht vermutlich nicht umsonst

Second, it is challenging to trigger Rowhammer corruptions without triggering corrections or crashes on a system protected by ECC.

Die Testsysteme sind AMD Bulldozer und Xeons.

Der Crash kann auch unabhängig vom RAM sein - der AMD Bulldozer kann ECC Fehlerinjektion zum Testen lt dem pdf paper - siehe auch memtest Changelog: https://www.memtest86.com/whats-new.html
aber "Note that injection support is typically disabled by AMD, except for some CPUs which are engineering samples."

Das Paper benutzt auch Hardware -Modifikation zum Erzeugen von ECC Fehlern.
Andere Forscher altern den RAM, damit sich dort ECC Fehler leichter bilden.
Außerdem sollten die Schutzmechanismen gegen die Angriffe deaktiviert oder zumindest bekannt sein -
so etwas wie hier tREF und andere Parameter - sind das überhaupt die Parameter, die du verändert hast ?
Gibt es überhaupt Daten zu Ryzen und Rowhammer angriffen und was haben die Leute da verändert ?

 

[Piktogramm]

BEACHTE Edit2, der Rest ist Makulatur


Lektüre
https://www.reddit.com/r/Amd/comments/bsszwg/ecc_ryzen_and_2bit_errors/

So richtig verwunderlich ist es nicht. ECC kann 1 fehlerhaftes Bit korrigieren und 2 fehlerhafte Bits erkennen, wobei fraglich ist, wie sich das System bei einem 2 Bit Fehler verhält. So wie du Fehler provozieren wolltest, ist es wahrscheinlich, dass dir mehr als 1Bit gekippt ist und du entsprechende Fehler hast.

Bei einem erkannten 2bitigem Fehler würde ich einen System halt bevorzugen[1]. Was aber auch bedingt, dass das Betriebssystem nichts mehr loggen kann[2]. Entsprechende Fehler müsste also auch das Motherboard parallel aufzeichnen. Das habe ich aber bisher nur "echten" Serverbrettern als Teil vom IPMI gesehen und das unterscheidet sich auch zwischen den Anbietern.
ECC und IPMI gibt es meines Wissens nach für AM4 derzeit nur von AsrockRack (gibt mehr als nur das Board) https://www.asrockrack.com/general/productdetail.asp?Model=X570D4I-2T#Specifications

[1] Ok kommt drauf an wo der Speicherfehler auftritt
[2] An sich ist vorgesehen, dass in solchen Fällen bestimmte Bereiche vom UEFI genutzt werden um dort hinein zu loggen. Damit habe ich mich aber selbst noch nicht beschäftigt.


Edit: IPMI hat wohl ein AMD Equivalent namens "DASH". Keine Ahnung wie/ob das irgendwo geboten wird und was diese Lösung können sollte.


Edit2:
Post vom 02.12.2019 von Nutzer Mastakilla
https://forum.level1techs.com/t/asrock-rack-x470d4u2-2t/147588/69

Der hat AsrockRack kontaktiert, AM4 kann ECC aber kein Reporting. Also eigentlich nur Spielzeug o.O

 

[jemandanders]

@Piktogramm
Hallo und vielen Dank für deine kleine Recherche.

AM4 konnte zumindest mal Error Reporting auf AM4. Zwar auch nicht ganz was man allgemein erwartet, aber immerhin. Damit wäre ich für meine Zwecke erst einmal Zufrieden gewesen. So das man bei einer Meldung eben mal genauer nachschaut.
Mit Memtest86 werden klar korrigierte ECC Fehler gemeldet. Auch schon bei "nur" 16er Timings. Bei meinen Versuchen muss es also Fehler gehagelt haben. Weder Ubuntu noch Windows Pro bekommen davon jedoch etwas mit.
Das Board hat zwar auch einen Bios Eintrag Error Injection, passieren tut dabei aber auch nichts. (Was soll das dann bitte?)
Vermutlich wurde Error Reporting bei der Überarbeitung des Speichercontrollers für Ryzen 3000 entfernt. Wie Dumm kann man denn bitte sein?
AMD war da zur Zeit eines Dirk Meyer mal nicht nur führend, sondern geradezu vorbildlich. Und die Plattform war auch "nur" AM3. Es ging also.
Ich glaube nicht, das sich AMD damit einen Gefallen tut, auf den Semi Pro Markt zu verzichten. So werden sie dort jedenfalls keinen Fuß auf den Boden bekommen.

Ich bin jetzt jedenfalls erst einmal aus der AMD Nummer raus. Threadripper ist ja vermutlich auch nur professionell angehauchte Spielbude und 24 Kerne brauch ich eh (noch) nicht. Wenn sie irgendwann einmal etwas für etwas gehobenere Qualitätsansprüche bringen sollten und die Eigenschaften klar und deutlich kommunizieren, werde ich vielleicht noch einmal auf die zurück kommen.
Montag bestelle ich mir das Fujitsu D3598. Da weiß ich jedenfalls was ich bekomme. Auf Wundertüte hab ich jetzt wirklich keine Lust mehr. Schon genug Zeit verplempert.

 

[Piktogramm]

Jain, das was in deinem Link gezeigt wird schaut eher danach aus, dass das Betriebssystem die CRC Events protokolliert. Was etwas anderes ist als ein Board welches diese Protokollierung betreibt.

 

[jemandanders]

Ja, das sind nicht die Meldungen, welche man sonst erwartet. Aber immerhin eine Meldung.
Wenn so etwas auftauscht, könnte man dann immerhin Nachforschen.
Ich habe jetzt auf Planet 3dnow noch etwas gesehen, was ich durchaus interessant fand.
AMD hat ab Agesa 1003abb eine WHEA Meldung ID 17 blockiert/abgeschaltet/entfernt.

Das bezieht sich zwar auf Windows, könnte aber vielleicht trotzdem relevant sein.
Das sind ja korrigierte Hardwarefehler. Könnte das auch das weiterreichen der ECC Korrektur verhindern?

 

[Piktogramm]

Nunja, "Nachforschen" geht da nur, wenn das Betriebssystem schafft zu loggen. Linux würde das System hart anhalten, wenn ein 2Bit Fehler in Bereichen auftreten würde, die vom Kernel belegt werden. An der Stelle wäre nichts im Log zu finden. Nur bei 2Bit Fehlern im ungenutzen Bereich oder Userspace würden protokolliert werden[1]. "Nachforschen" wird da im Zweifelsfall schwierig, der Fehler wird kaum konstant auftreten, da durch adress randomization der Fehler nur schwer reproduzierbar sein wird.

Nach allem was ich gefunden habe ist Event17 ein Fehler auf dem PCIe Bus. PCIe ohne Fehlerkorrektur würde den PCIe Standard verletzen und wäre generell dämlich. Ich gehe davon aus, da wird AMD die Fehlerkorrektur nicht abschalten.

[1] Keine Ahnung was BSD/MacOS oder Windows tun. Wahrscheinlich ist das Verhalten recht ähnlich.

 

[lokon]

Der verlinkte Hardwarecanucks-Artikel schreibt

Based on our findings, there is clearly some level of ECC functionality that is working right now, but it does not cover the full spectrum of memory error detection and correction.

Vermutlich ist ein Problem das AMD für Zen / Zen+ / Zen 2 selbst nach ~3 Jahren seit Erscheinen kein "BIOS und Kernel Developers Guide" = BKDG öffentlich herausgegeben hat.
Auf: https://developer.amd.com/resources/developer-guides-manuals/

ist solches für Bulldozer (15h - Liste der Familien v. AMD) gelistet
Intern existiert dies vermutlich, siehe zB reddit , neben ECC sind auch Temperatursensoren ein Grund für den Wunsch nach Dokumentation.

Wenn hwcanucks schreibt

Since Ryzen processors have internal ECC detectors for the L1, L2 and L3 caches, and we can’t separate the cache from the memory, it is hard to determine which component is actually causing the errors

dann - ohne AMD Experte zu sein - wundert mich die PPR / Open Source Register Reference hier
listet neben L2 , L3 mit "CECC/UECC" auch UMC (Unified Memory Controller) mit diesen CECC/UECC Registern auf. Da wird nahegelegt das memory + cache (und auch andere Teile) ECC Fehler in "MSR" Registern melden
Solche Dokumentationen gehen allerdings sehr in die Tiefe . "Einfach Ausprobieren was da steht" ist nicht so einfach.

 

[mae]

Also ohne an den Timings herumzuspielen, wirst Du bei funktionierendem Speicher nur extrem selten ECC-Korrekturen sehen. Wir haben bei unseren ersten Ryzen-Systemen mit Speichertimings herumgespielt; bei einem der beiden Systeme hat es einige Versuche gebraucht, um Timings zu finden, die zu ECC-Korrekturen (also Einzel-Bit-Fehlern), aber nicht zu Abstuerzen gefuehrt haben. Siehe https://www.complang.tuwien.ac.at/anton/ryzen-server.html#ecc1

Wenn das RAM selbst Rowhammer-immun ist (was bei vielen DDR4-RAMs so sein soll), wird die Rowhammer-Attacke nicht den gewuenschten Erfolg bringen.

P.S.: Wir sahen die Fehler mit dmesg. Unser 3900X-basierter Server ist derzeit im Produktiveinsatz, da koennen wir solche Tests im Moment nicht durchfuehren.

 

[jemandanders]

Also ohne an den Timings herumzuspielen, wirst Du bei funktionierendem Speicher nur extrem selten ECC-Korrekturen sehen.

Habe ich ja. Sogar mehr als ich jemals für möglich hielt. cl15 lief noch. cl14 meh.
Als ich Memtest86 free mit cl16 habe laufen lassen, gab es einige Meldungen. Das gibts aber nur mit Memtest.
Die Betriebssysteme bekommen davon aber nichts mit.
cl16
cl19

Man könnte halt sagen, wenn der Speicher unter Memtest86 und cl17 ohne korrigierte Fehler arbeitet, kann man bei normalen Timings damit durchaus leben.
Ich habe jetzt mal etwas drüber geschlafen und denke ich werde den Rechner dann doch produktiv benutzen.
Ich werde dann halt 1 x im Jahr überprüfen müssen ob der Speicher noch immer stabil läuft.
Vielleicht gibts ja doch irgendwann einmal Pro CPUs im Handel? So dass das dann alles korrekt funktioniert wie es eigentlich sollte?
Für die Zukunft bin ich auf jeden Fall erst einmal geheilt.