☰

Wie kann ich feststellen, ob RAM ECC funktioniert?

tag-icon • tag-icon linux-kernel ram ecc
Wie kann ich feststellen, ob RAM ECC funktioniert?

Ich habe vor, mir ECC-RAM zuzulegen, um den Nicht-ECC-RAM zu ersetzen, den ich derzeit auf meinem Asus M5A97 Pro-Motherboard (AMD 970-Chipsatz, FX-6100-CPU) installiert habe.

Nachdem ich den RAM installiert habe,Wie erkenne ich, ob die ECC-Funktion des RAM ordnungsgemäß funktioniert?

Ich habe mir überlegt, dmidecode --type memorywas derzeit unter anderem bei den einzelnen RAM-Riegeln ausgedruckt wird:

Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits

(Zum einen würde ich erwarten, dass bei 1 Bit ECC pro Byte die Datenbreite bei 64 Bit bleibt, die Gesamtbreite zum Lesen jedoch 72 Bit beträgt.)

Kann das verwendet werden, um zu bestimmen, ob ECC funktioniert? Oder ist dmidecode dafür zu niedrig? Was könnte ich sonst verwenden (außer abzuwarten und zu sehen, ob in den Protokollen ein ECC-Fehler angezeigt wird, der anzeigen würde, dass es funktioniert, aber nicht, dass es nicht funktioniert)?

Aktualisieren:Ich habe später an edac-utils gedacht. Als ich sie installierte, bekam ich Not enabling Memory Error Detection and Correction since EDAC_DRIVER is not set. Das gab mir edac-utilund edac-ctlausführbare Dateien. Kann eine davon für diesen Zweck verwendet werden?

Antwort1

AnscheinendEs gibt keine todsichere Methode, das zu sagen, allerdings können verschiedene Ansätze zu einer Antwort führen. Anscheinend muss man so ziemlich alles ausprobieren, bis man einen findet, der einem sagt, dass ECC funktioniert.

In meinem Fallmemtest86+ 4.20Ich konnte nicht dazu gebracht werden, zu erkennen, dass es sich um ECC-RAM handelte; selbst wenn ich es für ECC On konfigurierte, meldete es immer noch ECC: Disableddie IMC-Zeile. Ich habe es noch nicht mit einer neueren Version versucht. Allerdings (möglicherweise nach der Installation von edac-utils, leider habe ich beides im Wesentlichen gleichzeitig gemacht) meldet Linux in den Boot-Protokollen (durchsetzt mit einigen anderen Einträgen):

[    4.867198] EDAC MC: Ver: 2.1.0
...
[    4.874374] MCE: In-kernel MCE decoding enabled.
[    4.875414] AMD64 EDAC driver v3.4.0
[    4.875438] EDAC amd64: DRAM ECC enabled.
...
[    4.875542] EDAC amd64: CS0: Unbuffered DDR3 RAM
[    4.875545] EDAC amd64: CS1: Unbuffered DDR3 RAM
[    4.875546] EDAC amd64: CS2: Unbuffered DDR3 RAM
[    4.875548] EDAC amd64: CS3: Unbuffered DDR3 RAM

was ein ziemlich guter Hinweis ist. Wenn Sie dies manuell tun, /etc/init.d/edac restartwerden keine ähnlichen Protokolleinträge erstellt. Wenn ich mir ein älteres Protokoll von vor ein paar Neustarts anschaue, sehe ich:

[   13.886688] EDAC MC: Ver: 2.1.0
[   13.890389] MCE: In-kernel MCE decoding enabled.
[   13.891082] AMD64 EDAC driver v3.4.0
[   13.891107] EDAC amd64: DRAM ECC disabled.
[   13.891116] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
[   13.891117]  Either enable ECC checking or force module loading by setting 'ecc_enable_override'.
[   13.891118]  (Note that use of the override may cause unknown side effects.)

dmidecode --type memorygibt auch zwei ziemlich starke Hinweise: die Eigenschaft "Fehlerkorrekturtyp" des physischen Speicherarrays (die jedoch aus irgendeinem Grundzeigte das gleiche auf nicht-ECC RAM, daher kann es eher an der Unterstützung des Motherboards liegen als an den Speicherfunktionen),

Handle 0x0026, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: Multi-bit ECC

und die Gesamtbreite bzw. Datenbreite jedes Speichergeräts (die zusätzlichen Bits werden für den ECC verwendet):

Handle 0x0028, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x0026
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits

Antwort2

Dafür gibt es eine sehr einfache und effektive Möglichkeit, vorausgesetzt, Sie haben Konsolenzugriff auf Ihren Server/PC und können ihn neu starten:memtest86+

Dieses praktische Tool zeigt Ihnen schnell an, ob der Speicher ECC-fähig ist. Ich glaube auch, dass es beim eigentlichen Test eine ECC-Validierung durchführt.

Hier ist ein (etwas veralteter) Screenshot: Bildbeschreibung hier eingeben

Antwort3

Ich werde versuchen, meine Erfahrungen mit tatsächlicher Hardware zusammenzufassen. Ich habe keine M5A-Boards, aber zwei M4A-Boards mit AMD-Chipsätzen.

AM3

Ein paar Punkte:

  • M4A8xx-Motherboards unterstützen offiziell ECC.
  • AMD Phenom II und Athlon II unterstützen ECC. (andere funktionieren möglicherweise)
  • AMD Phenom-Chips unterstützen die Fehlerberichterstattung durch das Modul „edac_mce_amd“. Dieses Modul arbeitet ohne ECC und meldet Cache- oder andere mit der CPU zusammenhängende Fehler.
  • RAM ECC wird durch „amd64_edac“ unterstützt.

Zu diesem Zeitpunkt habe ich die M4A-Platine seit über 2 Jahren mit ECC-RAM laufen lassen und habe keine Fehler gemeldet bekommen. Einige Platinen scheinen keine korrigierbaren Fehler (CE) zu melden. Ich rate Ihnen, instabile Timings ohne ECC einzustellen und es anschließend zu aktivieren, um zu prüfen, ob es funktioniert. Sie können Memtest86 verwenden, aber diese Software meldet keine ECC-Ereignisse, sondern zeigt nur an, dass der RAM jetzt mit aktiviertem ECC stabil ist. Der Kernel selbst zeigt nur Meldungen ohne Details an, unabhängig davon, welche Kernel-Parameter an den Boot-Parameter „mce“ übergeben werden:

[Hardware error] Machine Check Exception

Diese werden auch in den 'edac'-Einträgen in /sys nicht berücksichtigt. Tests zufolge handelt es sich hierbei um korrigierte Fehler, aber ich weiß nicht, wie mit nicht korrigierbaren Fehlern umgegangen wird.

Diese ASUS-Boards scheinen auch keine Fehler im Zusammenhang mit CPU-Fehlern zu melden. Ich wurde mir dieser Funktion zum ersten Mal bewusst, als ein beschädigtes ASRock-Board zu blockieren begann, dies aber aufgrund von UE dem Betriebssystem meldete. Auf kompatiblen Boards werden diese in den Kernel-Meldungen im folgenden Format angezeigt:

[Hardware error] Machine Check Excpetion logged
[Hardware error] ERROR DETAILS, ETC, ETC

Diese werden nicht im MCE-Protokoll aufgezeichnet, sondern speziell vom Kernel verarbeitet. (Das Modul edac_mce_amd) Dies ist nützlich, da nicht korrigierte Fehler verworfen werden können, wenn sie sich in einem Puffer befinden, oder mit einer anderen Option, beispielsweise dem Beenden eines Prozesses, dessen Speicher beschädigt würde.

Auf diesen ASUS-Boards wird die CPU-Fehlerberichterstattungfunktioniert nicht. Das ist ziemlich schlecht, weil es zu Datenbeschädigungen kommen kann, wenn das Netzteil oder das VRM des Motherboards beschädigt sind und Fehler erzeugen. Ich würde dies nicht verwenden, ohne die CPU-Stabilität regelmäßig zu testen.

AM4

Auf ASUS AM4-Boards funktionierten frühere Versionen als AM3, aber die Speicherfehlerberichterstattung funktionierte korrekt – Sie konnten /sys lesen und die Fehleranzahl abrufen oder das Kernel-Protokoll einsehen. Im aktuellen BIOS müssen Sie den RAS-Daemon installieren und den Befehl „ras-mc-ctl“ verwenden, um die Fehleranzahl abzulesen.

Ich habe die CPU-Fehlerberichterstattung und -behandlung auf diesen Plattformen nicht getestet.

verwandte Informationen