Bericht zu Ryzen ECC Error Reporting

T

tolga9009

Enthusiast
Thread Starter
Mitglied seit
03.02.2010
Beiträge
670
Servus,

da die Recherchen im Internet diesbzgl. unvollständig, widersprüchlich oder einfach nur verwirrend waren, habe ich mich einmal selbst diesem Thema gewidmet. Die weitverbreitete Meinung zu diesem Thema scheint zu sein: Ryzen (AM4) + ECC Memory funktioniert, aber es wird nicht an das OS durchgereicht. Leider kann man das nicht so einfach überprüfen, da kaum ein AM4 Board ECC Inject unterstützt. Die einzigen Boards, die diese Möglichkeit bieten, sind die ASRock Rack Boards. Bzgl. dieser Boards ist jedoch eine Support E-Mail im Umlauf, wonach wohl ECC Error Reporting nicht funktionieren würde.

Einer der anderen Möglichkeiten, Fehler zu provizieren, ist Übertaktung. Ich konnte jedoch niemandem im Internet finden, der das mal ausprobiert hat, um das Error Reporting zu überprüfen. Also habe ich es selbst ausprobiert. Mein System:

Ryzen 7 2700
ASUS PRIME X470-Pro, BIOS 5603
2x Samsung 16Gb DDR4-2666 CL19 ECC RAM, 1.2V (M391A2K43BB1-CTDQ)
OS: Arch Linux, Kernel 5.8.13

ECC ist im BIOS auf "Enabled" gestellt. Um die RAM-Fehler zu provozieren, habe ich den Speicher auf 3200MHz gestellt, Primäre Timings auf 16-18-18-36 gestellt und den RAM auf 1.35V gesetzt. Von dort aus habe ich unter Linux mprime im Blend Test eingesetzt und schrittweise die Spannung runtergesetzt, bis die ersten Anzeichen einer Instabilität erkennbar waren - das war bei mir bei 1.3V der Fall. Dann habe ich den Stress-Test laufen lassen und über "edac-util -rfull" mir die Info zu korrigierten Fehlern anzeigen lassen. Die Ausgabe:

Code: 
mc0:csrow2:mc#0csrow#2channel#0:CE:0
mc0: csrow2: mc#0csrow#2channel#1: 1 Corrected Errors
mc0:csrow2:mc#0csrow#2channel#1:CE:1
mc0:csrow3:mc#0csrow#3channel#0:CE:0
mc0:csrow3:mc#0csrow#3channel#1:CE:0
mc0:noinfo:all:UE:0
mc0:noinfo:all:CE:0

Im System Log taucht folgendes auf:
Code: 
Okt 06 17:02:57 estheim kernel: mce: [Hardware Error]: Machine check events logged
Okt 06 17:02:57 estheim kernel: [Hardware Error]: Corrected error, no action required.
Okt 06 17:02:57 estheim kernel: [Hardware Error]: CPU:0 (17:8:2) MC16_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc2040000000011b
Okt 06 17:02:57 estheim kernel: [Hardware Error]: Error Addr: 0x00000003b3fe5b00
Okt 06 17:02:57 estheim kernel: [Hardware Error]: IPID: 0x0000009600150f00, Syndrome: 0x0000ce100a400502
Okt 06 17:02:57 estheim kernel: [Hardware Error]: Unified Memory Controller Ext. Error Code: 0, DRAM ECC error.
Okt 06 17:02:57 estheim kernel: EDAC MC0: 1 CE on mc#0csrow#2channel#1 (csrow:2 channel:1 page:0x787fcb offset:0x600 grain:64 syndrome:0xce10)
Okt 06 17:02:57 estheim kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD

Ich hatte keinen System-Absturz und mprime hat keine Fehler gemeldet.

Zusammenfassend kann man also sagen, dass zumindest für die Kombination aus Pinnacle Ridge + ASUS PRIME X470-Pro die ECC-Funktionalität und das Reporting an das OS einwandfrei funktioniert. Ob das für andere CPUs / Boards / Kombinationen auch der Fall ist, muss getestet werden.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Werde ich am WE ebenfalls testen, mit Asrock X570 Taichi & B550 Taichi...
 
Was waren für Dich die „ersten Anzeichen einer Instabilität“ um den „Sweet-Spot“ für stabil genug für den Benchmark und schwach genug für RAM-Fehler zu finden? :)
 
Als ich von 1,32V auf 1,31V runtergegangen bin, ist alles ganz normal gewesen. Bei 1,31V auf 1,30V hingegen hat mein Rechner zum Booten mehrere Anläufe gebraucht, hat den Boot aber noch geschafft. Hätte es den Boot nicht geschafft, hätte ich auf 1.305V angehoben und damit getestet.

Mir ist es auch paar Mal bei passiert, dass ich zwar ins BIOS gekommen bin, beim Laden des Betriebssystems aber das System Rebootet ist. Das ist nah dran, von dort aus muss man feinschrittiger vorgehen.

Im Endeffekt ist es 'ne Fummelarbeit, brauche ich garnicht schön reden. Sobald die "Grenzspannung" aber gefunden war, ist der Fehler dann relativ zügig innerhalb von ca. 3 Minuten nach Test-Beginn aufgetaucht.
 
tolga9009 schrieb:
Leider kann man das nicht so einfach überprüfen, da kaum ein AM4 Board ECC Inject unterstützt.
Zum Vergrößern anklicken....

Memtest x86 Pro ab Version 6.0.0. kann ECC Injection, sollte damit mit jedem Board das ECC hat Funktionieren.
Hier ein Bild aus dem Jahr 2015: https://abload.de/img/20150516_114001qoxk2.jpg
Und ein Report aus 2017: https://abload.de/img/memtest_report_eccinj85oba.jpg

Zudem kann man Windows abfragen welche ECC Methode genutzt wird (wmic) : https://abload.de/img/ecc_win10_wmic_aida64d7p06.jpg
 
Phantomias88 schrieb:
Memtest x86 Pro ab Version 6.0.0. kann ECC Injection
Zum Vergrößern anklicken....
Das ist richtig. Die Option lässt sich aber nicht aktivieren, wenn die ECC Inject Register gelocked sind, was jedoch standardmäßig der Fall ist. Das ist auch sinnvoll so: man möchte ja normalerweise nicht, dass im produktiven Einsatz Speicherfehler induziert werden können. Zum Unlocken der Register ist eine Einstellung im BIOS notwendig, welches mein Mainboard nicht bietet. Überhaupt gibt's diese Option unter AM4 Boards nur bei den ASRock Rack Boards (afaik).
 
Es gibt im FreeNAS Forum einen sehr langen Thread zum Asrock Rack X470D4U2-2T und dessen ECC Unterstützung. Da wurde, wenn ich mich richtig erinnere, auch mit Übertaktung des Speichers getestet.
Ergebnis war wohl, dass das Reporting direkt ans OS funktioniert, aber nur wenn es auch im Bios auch so konfiguriert ist und nicht das IPMI als Meldestelle eingestellt ist.
 
Ich hab ein X470U4 non 10GBe

Also meine letzte Antwort von Asrock Rack Support lautet:

ECC funktioniert und korrigiert damit auch Fehler aber weder das OS noch das SLog vom Mainboard bekommen das mit. Unter Linux kann man sich wohl irgendwie das ganze anzeigen lassen aber ich bin Windows Nutzer :)

Asrock gab an das es nicht am Ryzen oder gar am Chipsatz liegt sondern am Sockel AM4 der dafür nicht geeignet ist (AMDs Schuld!).

Daraufhin haben die bei Asrock einen minikleinen Hinweiss in der Boardbeschreibung namens * conditional ecc error support+ gehängt....
 
Zuletzt bearbeitet:
tolga9009 schrieb:
Das ist richtig. Die Option lässt sich aber nicht aktivieren, wenn die ECC Inject Register gelocked sind, was jedoch standardmäßig der Fall ist. Das ist auch sinnvoll so: man möchte ja normalerweise nicht, dass im produktiven Einsatz Speicherfehler induziert werden können. Zum Unlocken der Register ist eine Einstellung im BIOS notwendig, welches mein Mainboard nicht bietet. Überhaupt gibt's diese Option unter AM4 Boards nur bei den ASRock Rack Boards (afaik).
Zum Vergrößern anklicken....
Ok, also Memtest x86 bootet mit einem Linux ist somit unabhängig vom OS welches installiert ist.
Das mit dem Unlocken der report Funktion ist mir neu.

Am AM4 Sockel liegt es bestimmt nicht, sonst würde ECC gar nicht funktionieren.
Auf dem PCB (Platine vom Mainboard) müssen eben auch die extra Leiterbahnen vorhanden sein, da kann nur der Mainboard Hersteller was ändern. ;)


Edit: Windows Event Log Rubrik System: https://abload.de/img/eventlog_ereignis-id_garzp.jpg
 
Zuletzt bearbeitet:
Wow.
Funktioniert am B550M Tuf Gaming mit nem 4750G.
Genau von dem Tag, wo ich mit Speichersettings gespielt hab.

Habe zwei solche Meldungen im Eventlog.
"
Behobener Hardwarefehler.

Komponente: Arbeitsspeicher
Fehlerquelle: Machine Check Exception

Die Detailansicht dieses Eintrags beinhalten weitere Informationen.
"
 
Das ist natürlich schon längst passiert. hier vor längerer Zeit :d => Multibit-ECC. Das war mit das erste, was mich interessiert hat, als ich den Renoir bekam.
Aber es wurde ja immer wieder spekuliert, dass das Reporting ans OS dann trotzdem nicht funktioniert.
Die zwei Fehler im Eventviewer sind nun der Beweis auch, dass es (zumindest in meiner Konfig mit dem Renoir Pro) wirklich funktioniert.

Oh mann, und ich hab die Antwort auf das "geht auch das ECC-Reporting" quasi fast immer schon vor der Nase gehabt. :fresse: Naja, jetzt ist es dokumentiert; ich habs im 4750G-Workstation-Thema angefügt.
 
Zuletzt bearbeitet:
Ich hab vor einiger Zeit mein Asrock X370 Killer SLI unter Linux testweise mit übertaktetem ECC-RAM betrieben und dort ebenfalls einen ECC-Error beobachten können.
 
DarkDeveloper schrieb:
Es gibt im FreeNAS Forum einen sehr langen Thread zum Asrock Rack X470D4U2-2T und dessen ECC Unterstützung.
Zum Vergrößern anklicken....
Das ist vermutlich der Thread, den du meintest: https://www.ixsystems.com/community/threads/freenas-build-with-10gbe-and-ryzen.77752/page-5

Bin dort auf einen interessanten Beitrag bzgl. des ASRock Rack X470D4U gestoßen:
I'm happy to report that, after disabling "Platform First Error Handling (PFEH)" in the BIOS, (corrected) single-bit are properly reported to the OS, also when overclocking / undervolting! So I'm now getting the same results as Diversity with his memory pin shorting method...
Zum Vergrößern anklicken....
PFEH muss also im BIOS deaktiviert sein, damit die ECC Error an das OS weitergeleitet werden können. Wenn man dies' tut, funktioniert es aber einwandfrei.

Desweiteren wird dort über das erfolgreiche Error Reporting eines Ryzen 9 3950X in Verbindung mit einem ASUS Prime X570-P berichtet. Unter Einbeziehung aller bisherigen Beiträge hier im Thread und im FreeNAS Forum, vermute ich mittlerweile, dass funktionierendes Error Correction und Error Reporting nicht die Ausnahme, sondern bei ASUS und ASRock Boards die Regel ist. Die kursierende E-Mail vom ASRock Support bzgl. AM4 Error Reporting ist also irreführend und falsch. Hier als Referenz, damit ihr nicht suchen müsst:

Dear xyz,

So many thanks for you detail experience.
We will share this information to RD

However we got AMD official respond today

* AM4 support ECC function
* AM4 does not support ECC error reporting function

Here is the conclusion:
AM4 platform CPU (Ryzen 1000,2000,3000 series) can all support ECC correction, but not ECC report function

Best regards,
Kevin Hsiueh
Asrock Rack Incorporation

Interessant wäre für mich jetzt noch an dieser Stelle ECC + A320 / A520 Boards - ich sehe zumindest keinen Grund, warum es nicht funktionieren sollte. Das würde sehr interessante Optionen im Low-Budget Segment ermöglichen.
 
tolga9009 schrieb:
Unter Einbeziehung aller bisherigen Beiträge hier im Thread und im FreeNAS Forum, vermute ich mittlerweile, dass funktionierendes Error Correction und Error Reporting nicht die Ausnahme, sondern bei ASUS und ASRock Boards die Regel ist. Die kursierende E-Mail vom ASRock Support bzgl. AM4 Error Reporting ist also irreführend und falsch.
Zum Vergrößern anklicken....

Nein, sowas, dabei hat auf mich der ASRock Rack-Support sooo einen gewissenhaften Eindruck gemacht ;)
(hatte zwei X470D4U im Sommer 2019 gekauft als es noch schlimmer als jetzt war, der Support hat dann aufgehört, auf meine Fehlermeldungen überhaupt zu reagieren)
 
Habe aktuell ein ASUS TUF GAMING A520M-PLUS, was seit dem neuesten BIOS Update (1202) sehr interessante Optionen bekommen hat: es lässt sich nun "Memory Error Injection" ein- und ausschalten, sowie "Platform First Error Handling" konfigurieren. Außerdem lässt sich Memory Scramble / Encryption konfigurieren - neben zig anderen Optionen. AMD CBS dürfte nahezu komplett unlocked sein. Interessant dürfte der Blick Richtung anderer A520 / B550 / X570 Boards sein - die werden das Update sicherlich auch bekommen bzw. haben es bereits.
 
Diese ECC-Optionen waren/sind beim B550M Tuf Gaming mit 1202 auch einzustellen. Musste nur wieder zurück auf 1004 weil PBO-Boost mit dem 1202 und Renoir nicht läuft.
 
Coole Sache! Musste leider auch zurück :(. Meine iGPU hat mit 1202 Artefakte produziert. Nach dem Downgrade lief aber alles wieder wie gewohnt. Bin mal gespannt, ob sie das beim nächsten Update beibehalten.
 
Hallo in die Runde, habe mich extra im Forum angemeldet um mich hier mal einklinken zu können. Mich beschäftigt seit Stunden, dass ich meine neue Workstation für Grafikarbeit nicht mit dem ECC-UDIMMS gestartet bekomme. Im Netz gibt es teils widersprüchliche Aussagen, doch an mehreren Stellen fand ich User, die einen solchen Prozessor mit ECC einsetzen konnten.

Hier die Komponenten:

Ryzen 7 3700X
Asus PRIME X570 PRO
2x Samsung 32GB DDR4-2666 CL19 ECC - unbuffered (M391A4G43MB1-CTD)

Nach dem Verdacht, ich müsste erst einen non-ECC DDR4 Riegel besorgen um im BIOS ggf. ECC zu aktivieren, fand ich heute zum Glück die Möglichkeit hier im ländlichen Raum trotz Lockdown für nen Arm und n Bein ein Kit zu kaufen. Damit gelang das Booten dann auch.

ECC auf AUTO ... nix. ECC auf ENABLED ... nix. BIOS flashen. Neueste Version besorgt.. 3201.
Nun 1001 Möglichkeiten den RAM zu konfigurieren. Lasse alles auf AUTO. ... nix. Kiste kommt nicht ins Bios.

Nach stundenlanger Recherche konnte ich bis jetzt keine eindeutige Erklärung dafür finden. Alle drei Komponenten müssten ECC unterstützen.

Meine letzten Ansätze wären
- "Memory Error Injection", sowie "Platform First Error Handling" im neuen Bios suchen und testen
- evtl. Erklärung: Liegt hier im ECC Bereich bei diesem Komponenten-Mix eine RAM-Begrenzung vor? ... die funktionierenden EEC Belege im Web auf 3700X hatten alle nur 16GB ... ob pro Riegel oder im Kit insgesamt weiß ich nicht mehr... aber ich bin ja nicht der Einzige, der langfristig auf 128 GB ECC RAM aufrüsten möchte...

Wenn hier irgendjemand Licht ins Dunkel bringen könnte, wäre ich sehr dankbar. Und die zigtausend anderen Hilfesuchenden auch ;).
Ansonsten kommt gut ins neue Jahr boyz n girlz..

Möge das Bios mit euch sein.
 
Servus, eingangs hielt ich es erstmal für sehr unwahrscheinlich, dass beide brandneue Speicherriegel defekt sind. Obfohl das bei einer fehlerhaften Charche ja zwangsläufig der Fall wäre... Habe sie jedenfalls auch einzeln auf dem vorgesehenen Dimm-Slot probiert... bei beiden nichts... Werde aber den Händler mal kontaktieren und schauen ob sich da was machen lässt.

Durch die vielen teils widersprüchlichen Aussagen im Netz zu Gen. 3 geht/geht nicht ... Picasso/Matisse/Renoir mal ja mal nein.. nur mit Pro/auch ohne Pro etc ... hab ich halt lange gedacht ich hätte mich beim Kauf im ersten Lockdown vertan oder fehlinformiert... ist halt alles schon bisschen her... nach ewigem Suchen scheint mir das unwahrscheinlichste nun doch zuzutreffen o_O ... neuer Ram defekt :rolleyes2:

Es sei denn hier weiß jemand mehr...
Wüsst jedenfalls weit und breit niemanden mit nem ähnlichen Aufbau, wo mans testen könnte.
 
Also eigentlich sollte es mit aktiviertem ECC klappen. Aber selbst wenn ECC als solches nicht funktioniert, sollte das System ohne ECC-Funktion laufen. Daher der Verdacht, dass der RAM defekt sein könnte. Samsung-Module haben ja ein gut programmiertes SPD und sind sehr kompatibel.
 
Also ich hab original Samsung ECC-Udimms (16GB, 2 Ranks) am Laufen. mit 1T Commandrate
B550 (mit 4750G) : 2*16GB M391A2K43BB1-CTD (@ 3200 CL16-18-18-18, 1.37v)
X570D4U-2L2T (mit 5600X) 4*16GB M391A2K43BB1-CTD (@ 3066 CL 18-18-18-18, 1.37v) . 4x16er Module @ 3200 laufen NICHT bei mir mit dieser Spannung (komme da nur noch sporadisch ins Bios), höher will ich aber nicht gehen.
(=> sind also B-Dies drauf.)

Beim 4750G etwas intensiver getestet (Windows (inkl. ECC-Fehlereinträge im Eventviewer! ), BSD, Memtest), beim 5600X mit Memtest sowie Windows (berichtet auch hier Multibit ECC) und BSD/Linux mit den bekannten Abfragemethoden. Allerdings hab ich da bei Windows nicht im Eventviewer geschaut (hab auch den Ram aus Zeitgründen nicht so haarscharf auf die Grenze getrieben).

Wichtig: Vor dem Einsetzen der ECC-Module sollten XMP-Timings/Einstellungen aus dem Bios raus sein, d.h. Cmos-Clear oder manuellem Zurücksetzen. So dass man erstmal Basiseinstellungen hat.
Dran denken, dass die möglichen Timings beim Speichercontroller der Ryzens von der Rank-Anzahl abhängen! Beim 4750G sind daher die obigen Timings noch im Rahmen der AMD-Specs, beim 5600X nicht mehr (da 4 Module a 2 Ranks; da sieht AMD nur noch 2933 vor).

Sind aber alles 16er Module. 32GB-Module hab ich noch keine in der Hand gehabt und getestet.
 
Zuletzt bearbeitet:
******* schrieb:
Wie hast Du bei dem Brett die Spannung angehoben? Kann zumindest bei meinem nix dazu finden.
Zum Vergrößern anklicken....
Im Bios (aktuelle Betaversion 1.28) : Advanced - AMD-Overclocking (Accept) - Onboard Voltage Controls - VDDIO
Und dann die VDDIO Voltage Control auf "Increase" und als Adjust Mem VDDIO Value "60" eingetragen (=180mV mehr, als Basis hast ja die 1.2V aus dem Jedec-Profil. jeder value zählt als 3mV).
:bigok:
Ok, sind 1.38V (1.37V waren angepeilt, die +0.01 sind Schwankungsreserve).

Ggü. dem B550+4750G (mein Desktop) hab ich auch die Timings am Server etwas entschärft (CL18 statt 16), damit der Ram etwas mehr Reserve hat und nicht unnötig auf die Idee kommt, Bitfehler zu erzeugen und/oder das System unter Last zu crashen.
Aber ein bissl moderates Tempo für Zen2+3 muss schon sein; die B-Dies sollen kein Moos ansetzen.
 
Zuletzt bearbeitet:
@ryzfix
Ich habe das gleiche Setup wie Du:
- Ryzen 7 3700X
- Asus PRIME X570 PRO
- 2x Samsung 32GB DDR4-2666 CL19 ECC - unbuffered (M391A4G43MB1-CTD), s. a. Sammelthread HARDWARELUXX SPD Datenbank V2

allerdings noch das BIOS 2606 und keine Probleme unter Debian Testing, daher würde ich die ECC-Riegel mit Memtest V8.4 (oder neuer) testen.
Für den Test würde ich jegliche Peripherie (NVMe, SATA etc.) abklemmen.
 
ryzfix schrieb:
Mich beschäftigt seit Stunden, dass ich meine neue Workstation für Grafikarbeit nicht mit dem ECC-UDIMMS gestartet bekomme. Im Netz gibt es teils widersprüchliche Aussagen,
Zum Vergrößern anklicken....
Hier im Thread ging es primär darum zu verifizieren / zu zeigen, dass Ryzen Systeme mit ECC Speicher nicht nur "bootet", sondern tatsächlich auch Fehler behebt und das OS darüber informiert. Wenn ich das bei dir richtig verstehe, kriegst du dein Ryzen System mit ECC Speicher nicht einmal gebootet. Das ist ein gänzlich anderes Problem.

Die BIOS Einstellungen, die du genannt hast, helfen dir bei deinem Problem nicht. Die Einstellung "Enable ECC" sorgt lediglich dafür, dass ECC Speicher auch im ECC Modus läuft. Wenn der Eintrag auf "Disabled" gestellt wird, bootet das System weiterhin völlig problemlos, aber der RAM läuft nicht im ECC Modus und behebt somit keine Fehler.

"ECC Memory Injection" wird dir mit deinem aktuellen Problem auch nicht helfen. Das vereinfacht dir lediglich die Diagnose, dass ECC richtig läuft. Bei meinen Tests hatte diese Einstellung in Verbindung mit einem ASUS PRIME X470 Pro aber ohnehin keine Wirkung gehabt.

Ich fasse zusammen: du hast non-ECC und ECC Speicher probiert. Mit non-ECC bootet das System, mit dem ECC nicht. Du hast das aktuellste BIOS probiert (kein Erfolg). Du hast die ECC Riegel einzeln probiert, in verschiedene Slots (kein Erfolg). Das schließt eigentlich einen Defekt der RAM Riegel aus bzw. macht dies extrem unwahrscheinlich. Ich tippe auch, wie @Trambahner, auf falsche BIOS-Settings. Am besten den ECC-RAM einsetzen, CMOS-Reset über das Mainboard (Stromkabel abziehen -> bei ASUS mit einer Büroklammer o.Ä. Pins für ca. 10 Sekunden überbrücken, näheres in der Bedienungsanleitung) und dann Boot versuchen. Der erste Boot kann länger dauern und dein PC kann mehrmals neustarten. Das ist normal und wird als "Training" bezeichnet.

Damit du alles in einem Rutsch hast, am besten noch vorher die von @triple fault vorgeschlagene BIOS-Version 2606 drauf flashen.
 
Trambahner schrieb:
Also ich hab original Samsung ECC-Udimms (16GB, 2 Ranks) am Laufen. mit 1T Commandrate
B550 (mit 4750G) : 2*16GB M391A2K43BB1-CTD (@ 3200 CL16-18-18-18, 1.37v)
X570D4U-2L2T (mit 5600X) 4*16GB M391A2K43BB1-CTD (@ 3066 CL 18-18-18-18, 1.37v) . 4x16er Module @ 3200 laufen NICHT bei mir mit dieser Spannung (komme da nur noch sporadisch ins Bios), höher will ich aber nicht gehen.
(=> sind also B-Dies drauf.)

Beim 4750G etwas intensiver getestet (Windows (inkl. ECC-Fehlereinträge im Eventviewer! ), BSD, Memtest), beim 5600X mit Memtest sowie Windows (berichtet auch hier Multibit ECC) und BSD/Linux mit den bekannten Abfragemethoden. Allerdings hab ich da bei Windows nicht im Eventviewer geschaut (hab auch den Ram aus Zeitgründen nicht so haarscharf auf die Grenze getrieben).

Wichtig: Vor dem Einsetzen der ECC-Module sollten XMP-Timings/Einstellungen aus dem Bios raus sein, d.h. Cmos-Clear oder manuellem Zurücksetzen. So dass man erstmal Basiseinstellungen hat.
Dran denken, dass die möglichen Timings beim Speichercontroller der Ryzens von der Rank-Anzahl abhängen! Beim 4750G sind daher die obigen Timings noch im Rahmen der AMD-Specs, beim 5600X nicht mehr (da 4 Module a 2 Ranks; da sieht AMD nur noch 2933 vor).

Sind aber alles 16er Module. 32GB-Module hab ich noch keine in der Hand gehabt und getestet.
Zum Vergrößern anklicken....


Geht jetzt nicht so ganz klar daraus hervor, daher: Hast du ECC reporting auch auf dem X570D4U-2L2T getestet? Und was waren die Ergebnisse?
 
Nein, ich habe beim X570D4U nur die Funktion mittels den verschiedenen üblichen Shell-Abfragebefehlen geprüft. Reporting in IPMI oder Eventviewer nicht.
Ich kanns aktuell auch nicht mehr testen, da die Kiste nun im Einsatz ist.

Beim Rechner mit dem 4750G hatte ich dagegen echte Eventviewer-Einträge mit Fehlern. Eigentlich per Zufall entdeckt, als ich Rams ausgelotet hatte und wohl etwas zu hoch am Anfang.
 
Schade.

Ja, mein Brett ist auch schon produktiv (soweit man einen Server in einem Heimnetz ernsthaft als "produktiv" bezeichnen kann)....
Wenn ich meinen alten Barebone-Router auf opnsense umgestellt hab, werd ich das vielleicht mal testen. Auf die anderen Dienste kann der Haushalt dann auch mal n Tag oder zwei verzichten.
 
Kurze Info zu meinem neuen Dateiserver :

CPU : AMD R7-5800X
Mainboard : Asus Prime X570-PRO, BIOS : 3402
RAM : Kingston Server Premier, DDR4-2400 ECC, KSM24ES8/8ME
(2 Module á 8GB)
Betriebssystem : Aktuelles Manjaro KDE, Kernel 5.10.7
Zur kompatibilität bei Win10 kann ich nichts sagen,
denn das wird hier nie zum Einsatz kommen. Will ich hier nicht haben.

Das Mainboard wurde noch mit einer älteren BIOS Version (3001) ausgeliefert.
Der Rechner bootete damit ganz normal mit den beiden ECC Modulen und
ich kam auch ins BIOS. ECC wurde in Linux aber NICHT erkannt.
Das zweite RAM Modul in Sockel B2 habe ich dann testweise entfernt
und neu gestartet. ECC wurde auch weiterhin NICHT erkannt.
Als nächstes habe ich ein Upgrade auf BIOS 3402 gemacht. Dann den Rechner
ausgeschaltet, den Netzstecker gezogen und auch die CMOS-Batterie
für ca. 15min. herausgenommen, sodass das Mainboard komplett
zurückgesetzt wird.

Nun habe ich Manjaro frisch installiert und bekam folgendes Ergebnis :

Code: 
[storage-user@storage ~]$ uname -srm
Linux 5.10.7-3-MANJARO x86_64

[storage-user@storage ~]$ free
                   gesamt       benutzt     frei      gemns.  Puffer/Cache  verfügbar
Speicher:          15983        834         14495     70      653           14809
Swap:              17584          0         17584

[storage-user@storage ~]$ sudo dmesg | grep "EDAC"

[    0.593891] EDAC MC: Ver: 3.0.0
[    2.598463] EDAC amd64: F19h_M20h detected (node 0).
[    2.598507] EDAC amd64: Node 0: DRAM ECC enabled.
[    2.598507] EDAC amd64: MCT channel count: 2
[    2.598537] EDAC MC0: Giving out device to module amd64_edac controller F19h_M20h: DEV 0000:00:18.3 (INTERRUPT)
[    2.598540] EDAC MC: UMC0 chip selects:
[    2.598541] EDAC amd64: MC: 0:     0MB 1:     0MB
[    2.598541] EDAC amd64: MC: 2:  8192MB 3:     0MB
[    2.598544] EDAC MC: UMC1 chip selects:
[    2.598544] EDAC amd64: MC: 0:     0MB 1:     0MB
[    2.598545] EDAC amd64: MC: 2:  8192MB 3:     0MB
[    2.598545] EDAC amd64: using x16 syndromes.
[    2.598551] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[    2.598552] AMD64 EDAC driver v3.5.0

[storage-user@storage ~]$

So wie es aussieht, funktioniert es (hoffentlich).
 
Anmelden, um zu antworten.

Ähnliche Themen

M
Proxmox - Netzwerk mit Broadcom NIC
Antworten
10
Aufrufe
2K
Nemetron
Nemetron
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh