Mittels stress-ng den ECC Arbeitsspeicher RICHTIG belasten?

[mae]

Habe ich ja. Sogar mehr als ich jemals für möglich hielt. cl15 lief noch. cl14 meh.

Bei uns war bei einer Maschine mit cl-Aenderungen auch nichts zu holen (entweder keine Fehler oder Absturz (also Multi-Bit-Fehler)); erst mit Aenderungen der hinteren Timings haben wir auf dieser Maschine Single-Bit-Fehler beobachten koennen.

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.

Also nichts in dmesg? Wenn das memtest es von der Hardware gemeldet bekommt, spricht das eher fuer ein Betriebssystemproblem als eines der Hardware. Andererseits waeren davon wohl auch CPUs betroffen, die ECC garantiert koennen. Wurde der EDAC-Treiber seit 2017 ueberarbeitet?

Vielleicht gibts ja doch irgendwann einmal Pro CPUs im Handel?

Ab und zu sehe ich welche auf geizhals, aber die duerften wohl irgendwelche Reste von OEMs sein; als richtiges Boxed-Produkt von AMD waere schoen (oder wenn sie nicht noch mehr SKUs wollen, eben die Boxed-Produkte grundsaetzlich als Pro verkaufen, zumindest die teureren; ich kann's ja verstehen, wenn sie fuer einen Athlon 3000 nicht noch Tester-Zeit fuer ECC aufwenden wollen).

 

[jemandanders]

Bei uns war bei einer Maschine mit cl-Aenderungen auch nichts zu holen

Ich war eben nur Schreibfaul. Ich habe schon mehrere Parameter gesetzt.

Also nichts in dmesg? Wenn das memtest es von der Hardware gemeldet bekommt, spricht das eher fuer ein Betriebssystemproblem als eines der Hardware. Andererseits waeren davon wohl auch CPUs betroffen, die ECC garantiert koennen. Wurde der EDAC-Treiber seit 2017 ueberarbeitet?

Ich fand das ja auch komisch. Ich werde das noch einmal überprüfen.

 

[mae]

Wenn das ein bootbarer memtest war, dann vermute ich, dass der Linux-Kernel darunter einen EDAC-Treiber hat, der die Fehler meldet, waehrend Dein regulaerer Linux-Kernel das nicht meldet. Nur grob geraten, aber scheint mir am ehesten Deine Beobachtungen zu erklaeren.

 

[Piktogramm]

lsmod | grep edac

Einfach schauen ob edac geladen ist. Wenn nicht müsste man Gründe suchen und/oder das Modul von Hand laden.

 

[lokon]

Wurde der EDAC-Treiber seit 2017 ueberarbeitet?

Kernel - Log: Add family ops for Family 19h Models 00h-0Fh zB im Januar 2020
also schon Zen 3 kompatibel

Wenn "Rowhammer"-artige Angriffe oder Tests erfolgen, dann solte das ja theoretisch mit älteren Biosversionen (AGESA), älteren Linux-Kerneln, angepassten Linux-Kernel usw. "nachvollzogen" werden - also Forschungspapiere wie ECCSploit (s. auch vorheriger Beiträge) replizieren und dann von dort aus weitermachen

Im Anti-Rowhammer Patch Vorschlag : https://patchwork.kernel.org/patch/9401819/
wird zB DDR4 mit erfolgreicher Rowhammer-Attacke über JS zitiert...
Aber die meiste Forschung war original ja DDR3 und alte - besser dokumentierte Plattformen.

Es gibt aber auch einfachere Hobbys

PS: Anstelle eines Kernels kann genauso der Bootloader (der teilweise RAM, Hardware usw. initialisiert) direkt ein Programm laden - das macht ja gerade die Memtest Option - da ist dann kein Betriebsystem drunter sondern wird "bare Metal" genannt

 

[muce]

ECC-Unterstützung ist bei AMD-CPUs kaum ein Problem, bei Mainboards dagegen schon. Bist du sicher, dass dein MB das unterstützt? Schreibt der Hersteller zwar groß auf seiner Webseite, aber hat das mal jemand verifiziert?

Hast du die Fehlerkorrektur im RAM auch definitiv abgeschaltet? Wenn sie an ist, können MB und OS keine Fehler sehen.

 

[cgs]

Vielleicht noch eine Idee ECC zu testen: Kältespray direkt auf die RAMs.

 

[lokon]

Das Kältespray hilft eher beim Speichern von Daten im RAM.

Siehe Cold Boot Attack / Kaltstartattacke
Die vorher verlinkten Paper enthielten "artificial aging" und Modifikationen am DIMM Slot

 

[Piktogramm]

Hast du die Fehlerkorrektur im RAM auch definitiv abgeschaltet? Wenn sie an ist, können MB und OS keine Fehler sehen.

Wortdreher oder grundsätzlich falsche Aussage..