Desktop

Bus error

Chinawolf

Cadet 4th Year
Registriert
Feb. 2022
Beiträge
69
Komplexe DDR5-Stabilitätsprobleme auf AM5 trotz bestandener Speichertests

Ich stehe aktuell vor einem Problem, das sich seit mehreren Wochen nicht eindeutig eingrenzen lässt und mittlerweile eher nach einer Grenzbereichsproblematik zwischen Memory Controller, Infinity Fabric und DDR5-Training aussieht als nach klassischer RAM-Instabilität.

Hardware

  • Ryzen 7 9800X3D
  • ASUS X870E Hero (BIOS 1603)
  • 2×32 GB G.Skill Trident Z5 Neo DDR5-6000 CL30 (Hynix A-Die)
  • RTX 5080
  • Samsung 990 Pro 4 TB
  • Windows 11 24H2

Einstellungen

  • EXPO I aktiv
  • DDR5-6000
  • UCLK = MCLK (1:1)
  • FCLK 2200 MHz
  • Memory Context Restore aktiviert
  • Power Down Enable deaktiviert
  • VSOC aktuell 1,22 V
  • VDDIO Memory Controller 1,35 V
  • VDD/VDDQ laut EXPO-Profil

Das System läuft subjektiv absolut stabil. Es gibt keine Bluescreens, keine Anwendungsabstürze, keine beschädigten Dateien und keinerlei Auffälligkeiten im Alltag.

Das eigentliche Problem

Nach einigen Tagen Betriebszeit tauchen vereinzelt WHEA-19-Einträge im Ereignisprotokoll auf. Die Fehler sind korrigierbar und führen nicht zu Abstürzen.

Interessant ist jedoch:

  • Die Fehler treten niemals unter Volllast auf.
  • Sie erscheinen überwiegend im Idle oder während Lastwechseln.
  • Oft nach längeren Ruhephasen.
  • Teilweise kurz nach dem Aufwachen aus dem Energiesparmodus.
  • Manchmal mehrere Tage gar nicht.

Der WHEA-Eintrag verweist dabei regelmäßig auf:

«Cache Hierarchy Error»

oder

«Bus/Interconnect Error»

CPU-Kerne selbst scheinen jedoch stabil zu laufen.

Bereits durchgeführte Tests

Folgende Tests liefen ohne einen einzigen Fehler:

RAM

  • MemTest86 (4 vollständige Durchläufe)
  • Karhu RAM Test über 25.000 %
  • TestMem5 Anta777 Extreme
  • TestMem5 Absolut
  • y-cruncher VST
  • y-cruncher VT3

CPU

  • Prime95 Small FFT
  • Prime95 Blend
  • OCCT Large Data Set
  • Cinebench Dauerschleife

Alltag

  • Gaming über mehrere Stunden
  • Videobearbeitung
  • virtuelle Maschinen
  • große Datenkopien (>2 TB)

Keine Auffälligkeiten.

Auffällige Beobachtungen

Die Häufigkeit der WHEA-Einträge verändert sich deutlich bei bestimmten Einstellungen.

FCLK

2200 MHz:

- gelegentliche WHEA-19

2167 MHz:

- deutlich seltener

2133 MHz:

- bisher keine Einträge

Das deutet für mich eher auf die Fabric als auf den Arbeitsspeicher hin.

Memory Context Restore

Mit deaktiviertem MCR:

  • Bootzeit deutlich länger
  • bisher weniger WHEA-Einträge

Mit aktiviertem MCR:

  • schnellere Starts
  • Fehler treten häufiger auf

Daher besteht der Verdacht, dass gespeicherte Trainingswerte nach Temperaturänderungen oder längeren Off-Zeiten nicht mehr optimal zur realen Signalqualität passen.

Was mich irritiert

Normalerweise würde ich bei Instabilität erwarten:

  • Speicherfehler
  • Bluescreens
  • Abstürze
  • reproduzierbare Fehler unter Last

Hier passiert jedoch genau das Gegenteil:

Je stärker das System belastet wird, desto unauffälliger verhält es sich.

Die Ereignisse treten bevorzugt in Situationen auf, in denen die CPU zwischen verschiedenen Stromsparzuständen wechselt.

Deshalb frage ich mich, ob möglicherweise:

  • die Infinity Fabric an ihrer Stabilitätsgrenze arbeitet,
  • der integrierte Memory Controller einzelne Signalfehler korrigiert,
  • AGESA-Probleme im Zusammenhang mit DDR5-Training vorliegen,
  • oder ob moderne Ryzen-Systeme vereinzelt korrigierbare WHEA-Ereignisse schlicht als „normal“ betrachten.

Fragen an erfahrene AM5-Nutzer

1. Hat jemand vergleichbare WHEA-19-Ereignisse trotz vollständig bestandener Stabilitätstests beobachtet?

2. Gibt es bekannte AGESA-Versionen, die Probleme mit Memory Context Restore verursachen?

3. Ab welchem Punkt betrachtet ihr vereinzelte korrigierbare WHEA-Einträge als tatsächliche Instabilität?

4. Würdet ihr eher:

- FCLK reduzieren,
- VSOC weiter erhöhen,
- MCR deaktivieren,
- oder die Konfiguration trotz der Ereignisprotokolle als alltagstauglich betrachten?

Mich interessieren insbesondere Erfahrungen von Nutzern, die tiefer im DDR5-Tuning unterwegs sind und bereits ähnliche „läuft perfekt, aber WHEA meldet trotzdem etwas“-Szenarien analysiert haben.
 
Normalerweise wird empfohlen keinerlei Experimente bei den Einstellungen vorzunehmen die bekanntermaßen die Stabilität und Zuverlässigkeit massiv leidet. Ist das nicht eh sinnlos bei der CPU, bei der ja der RAM laut Test praktisch so gut wie keinen Einfluss hat?
 
  • Gefällt mir
Reaktionen: SSD960
Ein FCLK von 2200 Mhz ist doch weder Standard für Ryzen 9000 und noch dazu viel zu hoch, die wenigsten schaffen das. Standard sind doch 2000 Mhz bei DDR5-6000. Belass es dabei, du quälst die CPU ohne Grund.

Am Ende werden daraus permanente WHEA Fehler weil dir die erhöhten Spannungen den Controller grillen. Wäre auch nicht der erste Ryzen wo das passiert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SSD960 und TomTDooley
Na also wenn man den FCLK zu hoch dreht darf man sich über über Probleme nicht wundern wurde ja selber schon festgestellt.

Die Gedankengänge zu de Problem kann einfach nicht nachvollziehen FCLK hoch Probleme da FCLK runter Probleme weg wieso sucht man nach anderen Fehlerquellen wenn man das Problem doch schon erkannt haben muss ?
 
  • Gefällt mir
Reaktionen: Der Nachbar, SSD960 und Cerberus69
eher sollte der FCLK im Verhältnis zum Busspeed sein also 2000:6000 um Verzögerungen zu vermeiden.
 
  • Gefällt mir
Reaktionen: SSD960
Sämtliche Übertaktungen rausmachen und Rechner nutzen statt sich womöglich noch die Hardware wegen 3% zu schrotten, die man niemals merken wird.
 
  • Gefällt mir
Reaktionen: Fujiyama, SSD960 und Cerberus69
Auch ich würde alles im Standard betreiben und dann weiter schauen. Eigentlich das erste was ich machen würde um Fehler abzustellen.
 
  • Gefällt mir
Reaktionen: Cerberus69
Ist das Bios nicht schon auf 2404?
Welchen Speicher hast du genau? F5-6000A3038F16GX2-TZ5NXRK, F5-6000J3038F16GX2-TZ5NR, F5-6000J3040F16GX2-TZ5RK?
 
Aus noch aktuellen Anlass zu FCLK. Ich werde mir das Video noch in Ruhe anschauen, aber zu nicht konformen Grundeinstellungen wurde ja schon viel gesagt und mir solchen Sachen an die man die Hand angelegt hat, tauscht man sich im OC Unterforum aus um es zu stabilisieren oder höher zu gehen. Mit einem Hero Brett hat man sicher gute Voraussetzungen, mit der CPU ist es immer eine Lotterie.
Naja, Produktivanwendungen die auf die gesamte Hardware zugreifen verhalten sich nochmal anders als Stabilitatstests, was man gemerkt hat und da können einzelne Spannungen bei Taktwechseln innerhalb der einzelnen Logikgruppen zu stark einbrechen. Hat man auf die Zwischenspannungen keinen Zugriff, hat man keine Kontrolle.

 
Zuletzt bearbeitet:
Sapphire Forum
Zurück
Oben