ECC-RAM-Unterstützung für AMD Ryzen 7000 Desktop-CPUs bestätigt

 (sunshowers.io)
2 Punkte von GN⁺ 2023-10-10 | 1 Kommentare | Auf WhatsApp teilen
  • Die ECC-RAM-Unterstützung, die zum Start von AM5 aus den Spezifikationsblättern verschwunden war, wurde nun erneut durch einen funktionierenden Fall mit Ryzen 7000 „Raphael“ und einem ASRock-Mainboard bestätigt
  • Der Test wurde mit einem Ryzen 7950X, ASRock B650E PG Riptide, UEFI 1.28, AGESA 1.0.0.7b und zwei v-color 32GB ECC UDIMMs durchgeführt; nach dem DDR5-Link-Training bootete Linux erfolgreich
  • Die 72-Bit-Speicherbreite und die Anzeige Multi-bit ECC in dmidecode sind nützliche Hinweise, stammen aber aus den SMBIOS-Informationen des UEFI und belegen für sich allein nicht, dass ECC tatsächlich aktiviert ist
  • Fragt man die AMD UMC direkt über das SMN ab, zeigt Bit 30 von UmcCapHi den aktivierten ECC-Status an; auch unter Linux wurde in ryzen_smu bestätigt, dass dieses Bit für beide Speicherkanäle gesetzt ist
  • Es wurde zwar keine echte Fehlerinjektion durchgeführt, aber da die EDAC-Logs des Linux-Kernels erst ausgegeben werden, nachdem das ECC-Aktivierungsbit der UMC geprüft wurde, ist das ein starkes Indiz dafür, dass ECC tatsächlich aktiv ist

Veränderungen bei der ECC-Unterstützung auf Ryzen-Desktops

  • AMD Ryzen Desktop-CPUs hatten schon früher den Vorteil der offiziellen ECC-RAM-Unterstützung
    • Bei den meisten Ryzen-1000- bis 5000-Serien konnte ECC-RAM mit einem passenden Mainboard auch ohne deutlich teurere Workstation-CPUs genutzt werden
    • Die Spezifikationsseite des ASRock B550 Steel Legend ist ein Beispiel dafür, wie die ECC-RAM-Kompatibilität nach CPU-Generation detailliert aufgeführt wurde
  • Mit dem Start von Ryzen 7000 „Raphael“ und Socket AM5 verschwand der Hinweis auf ECC-Unterstützung
    • Selbst auf der Spezifikationsseite des hochpreisigen AM5-Mainboards ASRock X670E Taichi gibt es zum Zeitpunkt der Erstellung keinen Hinweis auf ECC-Unterstützung
    • Nach dem Upgrade auf einen Ryzen 7950X war die Leistung zwar zufriedenstellend, das Fehlen von ECC blieb beim Kauf aber ein großer Wermutstropfen

AM5-ECC-Tests, ausgelöst durch das ASRock-Forum

  • Im ASRock-Forenthread berichtete ein Nutzer namens ApplesOfEpicness von seinen Erfahrungen, ECC-RAM zusammen mit einem AMD-Ingenieur in der AMD-AGESA-Firmware zum Laufen gebracht zu haben
    • Er bestätigte, dass auf einem ASRock-Mainboard mit aktualisiertem UEFI ein Fehler bis zum OS gemeldet wurde, nachdem Datenpins und Masse kurzgeschlossen wurden
  • Für den anschließenden Test wurden ein ASRock B650E PG Riptide und zwei v-color 32GB ECC UDIMMs verwendet
    • Das Mainboard-UEFI wurde auf 1.28, AGESA auf 1.0.0.7b aktualisiert
    • Nach dem Austausch des RAM lief ein längeres DDR5-Link-Training, danach bootete das System
  • Auf diesem System dauerte das Link-Training mit 64GB RAM fast 3 Minuten
    • Bei Ryzen 7000 Desktop-CPUs ist das nur einmal nach einem RAM-Tausch oder einer Änderung der Timings nötig; UEFI cached das Ergebnis und verwendet es bei späteren Starts erneut

Sichtbare ECC-Hinweise unter Linux und ihre Grenzen

  • Unter Linux zeigt sudo dmidecode -t memory Werte mit Bezug zu ECC an
    • Error Correction Type: Multi-bit ECC
    • Total Width: 72 bits
    • Data Width: 64 bits
  • Besonders Total Width 72 bits ist ein auffälliges Signal
    • Bei Nicht-ECC-RAM werden 64 Bit angezeigt
    • 64-Bit-ECC-RAM besitzt zusätzliche 8 Bit für Paritätsdaten
  • Auch das EDAC des Linux-Kernels erschien als aktiviert
    • EDAC MC: Ver: 3.0.0
    • EDAC MC0: Giving out device to module amd64_edac
    • EDAC amd64: F19h_M60h detected

Warum dmidecode allein nicht ausreicht

  • dmidecode ist ein Tool, das die DMI- bzw. SMBIOS-Tabellen eines Computers menschenlesbar ausgibt
    • Diese Tabellen enthalten Informationen wie Hardware-Komponenten, Seriennummern oder BIOS-Revisionen
    • Man muss die Hardware nicht direkt abfragen, aber die angezeigten Informationen können unzuverlässig sein
  • SMBIOS definiert Datenstrukturen und Zugriffsmethoden zum Lesen von Verwaltungsinformationen, die vom BIOS erzeugt wurden
    • Dadurch muss das Betriebssystem Geräte nicht direkt selbst erkennen
  • Die ECC-bezogenen Informationen in dmidecode kommen nicht vom Prozessor, sondern vom UEFI
    • Manche Angaben wie Speichergeschwindigkeit können vom Speichercontroller stammen
    • ECC-Informationen kommen jedoch aus dem UEFI, was zwar zeigt, dass der Speicher ECC-fähig ist, aber nicht garantiert, dass ECC tatsächlich aktiviert wurde
  • Ob ECC aktiv ist, entscheidet letztlich der Speichercontroller des Systems

AMD UMC direkt abfragen

  • AMD-Prozessoren stellen einen Bus namens System Management Network, also SMN, bereit
    • Dieser Bus kann genutzt werden, um den AMD Unified Memory Controller, also UMC, abzufragen und zu konfigurieren
  • Über die AMD-UMC-Dokumentation von illumos lässt sich durch Abfrage des Registers UmcCapHi prüfen, ob ECC aktiviert ist
    • Die relevanten Informationen sind nicht Teil der öffentlich verfügbaren AMD Processor Programming Reference, lassen sich aber aus dem Open-Source-Code der Linux- und illumos-Kernel erschließen
  • Der direkte Zugriff auf SMN ist riskant
    • Insbesondere Schreibbefehle können einen Computer schwer beschädigen
    • Auf SMN sollten keine Schreibzugriffe ausgeführt werden
  • In illumos werden die beiden Speicherkanäle eines Ryzen-7000-Prozessors jeweils separat abgefragt
    • Kanal-0-Adresse: 0x50df4
    • Kanal-1-Adresse: 0x150df4
    • Der Rückgabewert war für beide Kanäle 0x40000030
  • Entscheidend ist Bit 30
    • Ist dieses Bit gesetzt, ist ECC im Speichercontroller aktiviert

SMN-Abfrage unter Linux mit ryzen_smu

  • Auch unter Linux kann über den Treiber ryzen_smu auf den SMN-Bus zugegriffen werden
    • Auf dem betreffenden System war für die Installation ein Patch erforderlich
  • Der Treiber stellt die Datei /sys/kernel/ryzen_smu_drv/smn bereit
    • Für eine Abfrage schreibt man die 4-Byte-Adresse im Little-Endian-Format und liest dann das 4-Byte-Ergebnis ebenfalls im Little-Endian-Format aus
  • Das Ergebnis der Abfrage beider Kanäle per Python-Skript war wie folgt
    • 0x00050df4: 0x40000000
    • 0x00150df4: 0x40000000
  • Die 4 im ersten Nibble des Rückgabewerts bedeutet, dass Bit 30 gesetzt ist; der Speichercontroller meldet also aktiviertes ECC
  • Auch unter Windows könnten ähnliche Abfragen mit Tools wie SMUDebugTool möglich sein, die Funktion dieser Tools wird hier jedoch nicht garantiert

Echte Fehlerinjektion und die Aussagekraft von EDAC

  • Der sicherste Weg, die Funktion von ECC zu verifizieren, ist die Injektion eines echten Fehlers
    • ApplesOfEpicness schloss Datenpins und Masse auf dem Mainboard kurz
    • Eine andere Methode wäre, RAM-Overclocking bis in einen instabilen Bereich zu treiben
  • In diesem Test wurden weder physische Kurzschlüsse an Pins noch wiederholte RAM-Overclocking-Tests durchgeführt
    • Dass DDR5-Link-Training jedes Mal mehrere Minuten dauert, macht Overclocking-Tests zusätzlich aufwendig
    • Bisher wurden keine natürlich auftretenden Fehler beobachtet
  • Der Meldungspfad der EDAC-Nachrichten im Linux-Kernel ist mit dem ECC-Aktivierungsbit der AMD UMC verknüpft
    • Die Log-Zeile Giving out device to module stammt aus edac_mc_add_mc_with_groups
    • Diese Funktion wird über den Pfad init_one_instance aufgerufen
    • init_one_instance wird nur aufgerufen, wenn pvt->ops->ecc_enabled wahr ist
    • Ryzen 7000, also Zen 4, gehört zur Familie 0x19; in diesem Fall wird umc_ops mit umc_ecc_enabled verwendet
  • umc_ecc_enabled prüft das UMC_ECC_ENABLED-Bit in umc_cap_hi
    • UMC_ECC_ENABLED ist Bit 30
    • Auf AMD-Prozessoren ist die Meldung EDAC MC0: Giving out device to module amd64_edac ein verlässlicher Hinweis darauf, dass die UMC aktiviertes ECC meldet

Fazit

  • Auch auf Ryzen-7000-Desktop-CPUs lässt sich ECC-RAM zumindest in Kombination mit ASRock-Mainboards relativ einfach betreiben
  • Die SMBIOS-basierten Angaben aus dmidecode allein reichen zwar nicht aus, aber zusammen mit Bit 30 der UMC und dem Linux-EDAC-Pfad lässt sich der aktivierte ECC-Status deutlich direkter bestätigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-10
Hacker-News-Kommentare

  • Ich brauche ein Prozessor-Upgrade und interessiere mich sehr für eine ECC-RAM-Konfiguration.
    Auf /r/AMD habe ich einen Thread gesehen, in dem zwei Leute darüber streiten, ob AMD-Prozessoren oder Mainboards tatsächlich ECC unterstützen, aber ich weiß nicht, wer recht hat: https://www.reddit.com/r/Amd/comments/lzxqod/list_of_am4_mot...
    Ich frage mich, ob dieser Artikel bestätigt, dass die Kombination AMD+ASRock wirklich ECC-RAM ist.

    • Beim Kauf eines Mainboards sollte man prüfen, ob in den Spezifikationen ECC-Unterstützung ausdrücklich angegeben ist.
      Normalerweise steht im Abschnitt „Memory“ etwas wie „ECC & Non-ECC, Unbuffered Memory“.
      Auf den Ausdruck „On-die ECC“ sollte man achten: Das ist eine Funktion, die auch Non-ECC-Speicher hat, und hat mit dem hier gemeinten ECC nichts zu tun.
      Man muss ECC DDR5 UDIMM kaufen und darf nicht versehentlich ECC DDR5 RDIMM kaufen, das mit AM5-Mainboards nicht kompatibel ist.
      ECC DDR5 UDIMM kann 80 Bit oder 72 Bit breit sein; nur 64 Bit wie bei Non-ECC DDR5 UDIMM darf es nicht sein.
      Als ich das früher geprüft habe, hatte ASUS die meisten AM5-Boards mit ECC-Unterstützung, und mir gefiel das PRIME X670E-PRO WIFI am besten, weil es abseits des GPU-Slots eine gute PCIe-Erweiterbarkeit bietet.
    • „Unterstützung“ bei ECC kann mehrere Stufen haben.
      0 bedeutet gar keine Unterstützung, sodass das System mit eingestecktem ECC-RAM nicht bootet; 1 bedeutet, dass man ihn einstecken kann, die ECC-Funktion aber nicht genutzt wird; 2 bedeutet, dass die Schaltung vorhanden ist, der Mainboard-Hersteller Fehlererkennung und -korrektur aber nicht validiert hat; 3 bedeutet, dass ECC-Funktionen vorhanden und vom Hersteller validiert sind.
      Bei Server-Boards wie von Supermicro kann man Stufe 3 erwarten.
      Wenn bei AMD-Prozessoren „ECC supported“ steht, ist schwer zu erkennen, um welche Stufe es geht; bei Intel kann man dagegen davon ausgehen, dass es tatsächlich unterstützt wird, wenn CPU/Chipsatz ECC unterstützen.
    • Zu ASRock weiß ich es nicht, aber auf ASUS-X570-Boards funktioniert ECC definitiv.
      Mit absichtlich defekten ECC-DIMMs konnte ich in kurzer Zeit korrigierbare und nicht korrigierbare Fehler erzeugen.
      Wenn alle anderen Komponenten vorhanden sind, erscheint es unwahrscheinlich, dass ASRock die Leitungen nicht verdrahtet hat; wenn der Kernel sagt, dass ECC vorhanden ist, würde ich das als korrekt ansehen.
      Andernfalls kann man das Board als defekt zurückgeben und einen anderen Hersteller nehmen.
    • Ich nutze ECC auf X570- und B550-ASRock-Boards, und ASRock erlaubt schon seit ziemlich langer Zeit unbuffered ECC.
      Schade ist allerdings, dass es keine mini-ITX/mATX-X670E-Boards gibt. Die hat nur ASUS.
    • Ich verwende eine Kombination aus ASRock X570 PG 4S + Ryzen 5 2600 + Kingston 32GB 2666 ECC, und auch in der CPU-/Speicher-Supportliste dieses Boards steht, dass ECC in dieser Konfiguration funktioniert.
      dmidecode meldet zwar eine Datenbreite von 128 Bit statt 72 Bit, berichtet aber auch Multi-Bit-Korrekturen statt nur Single-Bit-Korrekturen.
      Bei Intel-Boards mit UDIMM, etwa Supermicro+Xeon, war ich 72 Bit gewohnt, aber diese Information scheint eher davon beeinflusst zu sein, wie Speichercontroller und Mainboard berichten, als von der tatsächlichen Hardware-Unterstützung.
      Trotzdem funktioniert EDAC, der richtige Treiber wird registriert, und ich bekomme in EDAC/RAS gelegentlich Warnungen, dass korrigierbare Fehler tatsächlich korrigiert wurden; damit ist die Sache für mich ausreichend geklärt.

  • Etwas abseits des Themas, aber ECC-Unterstützung, die auch auf der älteren AM4-Plattform und mit Zen3-APU-Kernen funktioniert, sieht so aus und ist auf meinem System definitiv vorhanden.
    Es handelt sich um eine Kombination aus ASRock B550M-ITX/ac und AMD Ryzen 5 PRO 5650G; zuvor mit einem Ryzen 5 3600 und dedizierter GPU funktionierte es genauso.
    Um ECC-Aktivität auf aktuellem GNU/Linux zu erkennen und zu protokollieren, muss der Dienst rasdaemon aktiviert werden.
    Dieser Dienst interpretiert MCEs und andere hardwarebezogene Fehler und speichert sie in einer Datenbank; auch die oben abgefragte Ausgabe ist ein Ergebnis davon.

    • Bei einer solchen Fehlerhäufigkeit kann man durchaus das Gefühl bekommen, dass Informationen von einem Computer ohne ECC schwer zu vertrauen sind.
      Wenn man es sich noch einmal überlegt, ist die Häufigkeit allerdings ziemlich hoch, sodass möglicherweise ein Speichermodul defekt ist. Besonders, weil es jedes Mal dasselbe Modul und dieselbe Adresse ist.
    • APUs sind ausdrücklich von der ECC-Unterstützung ausgenommen, mit Ausnahme der PRO-SKUs.
      https://www.asus.com/global/support/FAQ/1045186/
    • Ich habe ECC-RAM in einem Gigabyte-B550I-System installiert; dmidecode zeigt eine Breite von 72 Bit, und dmesg | grep -i EDAC zeigt ebenfalls viele Informationen, die darauf hindeuten, dass ECC aktiviert ist.
      Die Ausgabe des betreffenden Befehls ist jedoch leer und zeigt nur „No Memory errors“, „No PCIe AER errors“, „No Extlog errors“, „No MCE errors“.
      Ich frage mich, ob man noch etwas aktivieren muss, damit Fehler protokolliert werden, oder ob ich von dmidecode und dmesg in die Irre geführt wurde.
    • Mich würde interessieren, welches Speichermodul du verwendest.

  • Guter Beitrag. In meinem Threadripper-Board verwende ich ebenfalls ECC-RAM.
    Eine der Erkenntnisse des Blekko-Betriebsteams bei Intel-Boards war, dass man dem Board ausdrücklich mitteilen musste, korrigierbare Fehler tatsächlich zu melden.
    Standardmäßig wurde bei nicht behebbaren Fehlern ein Machine Check ausgelöst, alles andere wurde einfach ignoriert.
    Ich meine, dass wir bei etwa 1.600 Systemen mit 192 GB ungefähr einmal pro Woche korrigierbare Fehler gesehen haben.
    An nicht behebbare Fehler erinnere ich mich in sechs Jahren an keinen einzigen, also war das ziemlich gut.

    • Da hatten wir noch mehr Glück. Unsere Systeme meldeten korrigierbare Fehler, ohne dass wir das gesondert anfordern mussten.
      Wir hatten eine ähnlich große Flotte und im Schnitt eine ähnliche RAM-Menge, und gelegentlich gab es auch nicht behebbare Fehler. Vermutlich ein- oder zweimal pro Jahr; daraus entstand eine Richtlinie.
      Wir beobachteten, ob es bei einem einzelnen Vorfall blieb; wenn es nicht bald wieder fehlschlug, galt es als in Ordnung, und wenn es bald erneut fehlschlug, tauschten wir den RAM.
      Bessere Server-Boards zeigen sogar per LED an, welches RAM-Modul gewechselt werden muss.
      Korrigierbare Fehler führten erst bei ziemlich hohen Zählwerten zu einem Austausch, und Systeme mit ein oder zwei Fehlern pro Tag liefen noch lange problemlos.
      Umgekehrt gab es Systeme, die lange bei 0 lagen, dann über ein paar Tage wenige Fehler zeigten und anschließend auf hohe Werte sprangen.
      Ein System kam auf Tausende pro Stunde und war wegen der Kosten für die Behandlung der Machine-Check-Exception praktisch unbenutzbar; da der Meldezyklus aber eine Stunde betrug, kannten wir die Ursache bis zur nächsten Meldung nicht.

  • Ich nutze derzeit einen Ryzen 3700X mit einem ASUS TUF Gaming X570-Mainboard und brauche mehr Single-Core-Leistung sowie mehr NVMe-/Plattengeschwindigkeit.
    Ich verwende bereits zwei GPUs, zwei M.2-NVMe und sechs SATA-Laufwerke.
    Ich denke über ein Upgrade zum Jahresende nach; wegen der PCIe-Lanes habe ich kurz auch an Threadripper gedacht, aber Zen4 Threadripper gibt es noch nicht und er dürfte sehr teuer werden.
    Die Optionen sind, auf einen Ryzen 5900X zu gehen und den Rest beizubehalten, oder mehr Geld auszugeben und auf AM5 Ryzen mit neuem Mainboard zu wechseln.
    Intel habe ich mir auch angesehen, aber als ich sah, dass es bei 20 PCIe-Lanes endet, tendierte ich dazu, es auszuschließen.
    Ich möchte einen 10Gb-Adapter hinzufügen und einige rotierende Festplatten auslagern, deshalb brauche ich mehr PCIe-Lanes.
    Die Multi-Core-Leistung des 3700X reicht aus, und wenn ich ein neues Mainboard kaufe, möchte ich für die Geschwindigkeit mindestens einen Mirror aus zwei NVMe-Laufwerken und mindestens sechs SATA-Ports.

    • Ich habe zwei NVMe als Mirror genutzt, aber es gibt viele Fallstricke, wenn man die maximale Leistung herausholen will.
      Bei AMD weiß ich es nicht, aber Intel-Boards haben meist nur einen M.2-Slot direkt an der CPU, die anderen drei laufen über den Chipsatz und teilen sich damit den Engpass auch mit der 10Gb-Ethernet-Karte.
      Am Ende war es viel schneller, ein Board mit PCIe-5.0-Unterstützung und eine ausreichend große einzelne SSD zu kaufen; sowohl die gesamten IOPS als auch der Durchsatz lagen über dem früheren RAID-0-Array.
    • Mich würde interessieren, bei welchen Workloads die NVMe-Geschwindigkeit zum Flaschenhals wird.
    • Ich nutze einen 5900X und habe das Gefühl, ich hätte warten und den 5800X3D kaufen sollen.
    • Wenn mehr nötig ist, ist es besser, zum 5950X zu greifen, der etwa 4/3 kostet, aber doppelt so viele Kerne hat, oder für Factorio-UPS eine CPU mit 3D-Cache in Betracht zu ziehen.
      Der 5900X ist kein so großes Upgrade.

  • Als Referenz: Hetzner bietet seit einigen Monaten Server mit Ryzen-7000-CPUs und ECC-RAM an.
    https://www.hetzner.com/dedicated-rootserver/matrix-ax
    Beim AX52 gibt es ECC-RAM als optionales Upgrade, beim AX102 ist ECC standardmäßig enthalten.
    Ich kann mir kaum vorstellen, dass sie ECC angeboten hätten, das tatsächlich nicht funktioniert.

    • Soweit ich weiß, entwickelt Hetzner eigene Mainboards oder lässt sie nach eigenen Vorgaben fertigen.
      Deshalb können sie ECC-Unterstützung wohl von Anfang bis Ende zuverlässig sicherstellen.

  • Ich wünschte, die Gesetzgeber würden zur Vernunft kommen und ECC verpflichtend machen.
    Es ist beunruhigend, dass der Großteil der Rechenarbeit auf anfälligen Non-ECC-Systemen stattfindet.
    Das ist eine besonders üble Form künstlicher Marktsegmentierung.

    • Du hast wohl die Anhörungen nicht gesehen, bei denen Abgeordnete Leute wie Zuck vorgeladen und gefragt haben, wie man ein Handy benutzt.
      Wie soll man erwarten, dass solche Leute zu ECC Gesetze machen?
    • Bei Non-ECC-Systemen von anfällig zu sprechen, ist schwierig, wenn sie 99,9999 % der Zeit völlig einwandfrei funktionieren.
    • Ich höre oft, Non-ECC-Maschinen seien völlig anfällig, und rechnerisch wirkt es, als müssten ständig Bitflips auftreten.
      Aber mein Intel-System läuft mit 64 GB Non-ECC-RAM jeden Tag einen halben Tag und geht nachts in den Ruhezustand; selbst mit 3D-CAD, Photoshop, VS Code voller Erweiterungen und WSL2-Docker-Containern sehe ich praktisch keine Fehler.
      Auch keine Abstürze oder Bluescreens.
      Ich frage mich, was man bei Bitflip-Fehlern eigentlich genau erwarten sollte. Wenn bei nahezu voll belegten 64 GB RAM so häufig einzelne Bits kippen, müsste sich das doch irgendwie bemerkbar machen.

  • Ich habe weder den Mut, physisch Pins kurzzuschließen, noch die Geduld, den RAM langsam zu übertakten und jedes Mal minutenlang auf das DDR5-Link-Training zu warten.
    Deshalb gebe ich mich damit zufrieden, dass der Speichercontroller meldet, ECC sei aktiviert.
    Wie wäre es stattdessen, warme Luft aus einem Föhn auf den RAM zu blasen? Ich habe früher gesehen, dass man so eine Methode verwendet, um Fehler zu erzeugen.

    • Aus kurzer Entfernung sollte ein Propan-Grillanzünder funktionieren. Solche Dinger erzeugen absurd starke elektromagnetische Störungen.
      https://hackaday.com/2022/01/29/blast-chips-with-this-bbq-li...
      https://hackaday.com/tag/emfi/
    • Realistischer ist, dass man bei einem laufenden System einen Teil des Memory-Overclockings in Echtzeit anpassen kann, ganz ohne Link-Training.
      Für den echten Einsatz ist das nicht zu empfehlen, aber zum Ausloten der Speichergrenzen oder zum Erzeugen von Fehlern kann man es nutzen.
    • Könnte man mit einem Rowhammer-Test prüfen, ob ein System ECC-RAM hat?
      Auf meinem nicht übertakteten I7-4770K-System treten Fehler zutage, aber ältere Supermicro-Boards der X10-Generation scheinen selbst bei unbegrenzt laufendem Rowhammer-Test keine Fehler zu erkennen.
      Falls moderne Systeme allerdings so entwickelt wurden, dass sie nicht für Rowhammer-Angriffe anfällig sind, funktioniert diese Methode möglicherweise nicht.
      Beim Raspberry Pi 4B und CM4 heißt es, dass deren RAM ECC-RAM verwendet, aber das ist nicht dasselbe ECC wie hier gemeint.
      Dabei handelt es sich um On-Die-ECC zur Verbesserung der Chip-Ausbeute; ECC-Fehler werden nicht über die Hardware gemeldet, sondern korrigiert.
      Nicht korrigierbare ECC-Fehler würden vermutlich einfach als falsche Daten gelesen.
      Ich frage mich, ob moderne RAM-Module ebenfalls Chips mit On-Die-ECC verwenden.
    • Könnte man nicht einfach ein Handy in die Nähe des DIMM halten und so Fehler auslösen? Das ließe sich leicht ausprobieren.
    • Bei einer High-Speed-I/O-PCBA, die zehn Jahre durchlaufen soll, erscheint mir das Risiko, eine BGA-Lötstelle erneut aufzuschmelzen, größer als das Kurzschließen eines durch Dioden geschützten Pin-Paars.
      Link-Training lässt sich im BIOS abschalten, sodass man schnell grenzwertige Bandbreiteneinstellungen finden kann.
      Die Ergebnisse werden nicht besonders gut reproduzierbar sein, aber das ist nicht wichtig.

  • Einige, vielleicht sogar alle ASUS-AM5-Mainboards haben offiziellen ECC-Support.
    Bei dem Modell, das ich gerade geprüft habe, steht es sowohl im Board-Handbuch als auch im BIOS-Handbuch.
    Eine der zugehörigen BIOS-Optionen steht standardmäßig auf Auto, ist in diesem Zustand aber entgegen der Intuition deaktiviert und muss daher geändert werden.
    ECC-Reporting für diese Prozessoren ist in Linux 6.5 gelandet, daher müssen Nutzer von Debian Stable warten, bis es in die Backports kommt, oder den klassischen Weg verlassen.
    https://www.phoronix.com/news/AMD-EDAC-Ryzen-7000-Series

    • Ich hasse Auto-Einstellungen im BIOS wirklich.
      Wenn man den tatsächlich angewendeten Wert sehen könnte, wäre es noch halbwegs okay, aber in neun von zehn Fällen ist es nicht eindeutig.

  • Es gibt Gerüchte, dass ältere AGESA-Versionen einen Bug hatten, der verhinderte, dass der Chipsatz ECC-RAM korrekt erkannte und nutzte.
    Und das, obwohl der betreffende Chipsatz ihn eigentlich unterstützen sollte.
    Bei Mainboards, die man in Betracht zieht, sollte man prüfen, ob es ein Firmware-Update mit mindestens AGESA 1.0.0.5 patch C gibt.
    https://www.reddit.com/r/truenas/comments/10lqofy/
    AGESA ist Teil der AMD-System-Firmware und initialisiert zentrale Systemkomponenten: https://en.wikipedia.org/wiki/AGESA

    • Nach dem ASRock-Forum-Thread klingt das plausibel.
      Ich habe vor dem Einbau von ECC-RAM auf AGESA 1.0.0.7b aktualisiert.

  • Ich wusste nicht, dass die Ryzen-7000-Serie ECC-Support nicht offiziell ausweist.

    • Nachdem ich diesen Beitrag veröffentlicht hatte, habe ich erfahren, dass es offiziell AM5-Mainboards mit ECC-Support gibt.
      Zum Beispiel unterstützt die ASRock-Rack-Reihe das: https://www.asrockrack.com/general/productdetail.asp?Model=1...
      Auch dieses ASUS-Mainboard behauptet, ECC zu unterstützen: https://www.asus.com/us/motherboards-components/motherboards...
      Beide gab es noch nicht, als ich mein erstes AM5-Mainboard gekauft habe. Das war direkt nach dem Launch, und die Leistungswerte waren so gut, dass ich früh zugeschlagen habe.
    • Das ist eine Fehlinterpretation des Autors.
      Alle derzeit erhältlichen Ryzen-7000-CPUs haben offiziellen ECC-Support, aber es braucht auch Mainboard-Support.
      Solcher bedingter ECC-Support war bei AMD-Consumer-CPUs eigentlich schon seit dem Athlon 64 durchgehend vorhanden, aber bei der Ryzen-7000-Serie sehe ich ihn, soweit ich weiß, zum ersten Mal in AMDs Marketingmaterialien ausdrücklich erwähnt.
      Der Autor meinte, dass der Hinweis auf ECC-Support aus der Dokumentation von ASRock-Mainboards verschwunden ist.
      Da ASRock bei früheren Ryzen-Mainboards ECC-Support angegeben hatte, war das eine auffällige Änderung.
      Beispiel der Spezifikationsseite des Ryzen 5 7600: https://www.amd.com/en/product/12756#:~:text=ECC%20Support,R...)
    • Bis vor diesem Jahr war das ziemlich vage und nicht klar erwähnt.
      Außerdem wird es mit dem On-Chip-ECC verwechselt, das alle DDR5 verwenden.
      DDR5 benötigt On-Chip-ECC, um Fehler zu korrigieren, die im normalen Betrieb auftreten, aber das ist kein ECC, das auch die über den Speicherbus zur CPU übertragenen Daten schützt.