5800X3D WHEA 18

Birdy84

Lötkolbengott/-göttin
Hallo Leute,

ich wäre für Hilfe beim Troubleshooting dankbar. Nachdem mein 5800X3D seit knapp einem Jahr manuell getunt lief, erzeugt seit etwa 6 Wochen Event ID 18 WHEA* Fehler bei Spielen (Hunt Showdown oder Ready or Not) in Form eines Resets. Drei Mal ist das bislang erst passiert. Seit dem zweiten Auftreten, wurde der CO deaktiviert (CPU nutzt wieder mehr Energie), aber der Fehler kam vor ein paar Tagen erneut. Daraufhin habe ich den IF Takt von 1900Mhz auf Auto sowie die Spannungen für SOC von 1,094V, VDDG IOD von 1,048V und CCD von 0,947V zurück auf Auto gestellt und den RAM auf 3200Mhz heruntergeregelt. Edit: Den Chipsatztreiber habe ich ebenfalls von amd.com aktualisiert.

*Schwerwiegender Hardwarefehler.

Gemeldet von Komponente: Prozessorkern
Fehlerquelle: Machine Check Exception
Fehlertyp: Bus/Interconnect Error
Prozessor-APIC-ID: 2
Es ist immer APIC-ID 2.

Mein Fragen sind:
1. Kann das am IF Takt bzw. den Spannungen liegen, obwohl immer der gleiche Kern betroffen ist?
2. Womit kann ich effizienter testen?

Edit2: Hiernach sind WHEA 18 Fehler auf VCore zurückzuführen und nicht auf den IF.
 
Zuletzt bearbeitet:
Was heißt "manuell getunt"? Auch OC? Falls ja, könnte der X3D durch sein, da gerade der besonders empfindlich reagiert.
Oder das Board hat einen weg.
Welches Agesa wird verwendet?
Gruß T.
 
Was heißt "manuell getunt"? Auch OC? Falls ja, könnte der X3D durch sein, da gerade der besonders empfindlich reagiert.
Oder das Board hat einen weg.
Welches Agesa wird verwendet?
Gruß T.
Das hätte ich klarer ausführen sollen. Damit ist gemeint: CO -30, 1900Mhz FCLK plus die o.g. Spannungen, CPPC Preferred Cores deaktiviert und manuell eingesteller RAM.
 
Hatte die exakt gleiche Meldung auf meinem 5900X.
Die CPU ist im Overboost (PBO) instabil.

Du kannst den Takt limitieren oder die Spannung erhöhen (geht beim X3D ja schlecht), dann ist das Ding stabil.
Wenn das Problem @Stock auftritt ist das ein Garantiefall, wenn es bedingt durch deine Settings auftritt dann...


Das war zu 5XXX Series Launch ein ziemlich oft auftretendes Problem, später hatte AMD das dann im Griff.
Die X3D - welche später gelauncht wurden - sind aber soweit ich weiß nicht betroffen.

Ich habe damals die CPU zu AMD nach Holland geschickt und hatte nach wenigen Tagen nen neuen Chip.
 
Du kannst den Takt limitieren oder die Spannung erhöhen (geht beim X3D ja schlecht), dann ist das Ding stabil.
Wenn das Problem @Stock auftritt ist das ein Garantiefall, wenn es bedingt durch deine Settings auftritt dann...
Die CPU läuft jetzt erstmal mit Standardeinstellungen und ich lasse über nach Prime95 in-place custom mit AVX durchlaufen.
 
Dann hat vllt doch das MB einen weg :ka:
Liefert das NT genug Saft auf der CPU-Schiene?
Schon komisch, das alles.
Gruß T.
Wie kommst du zu dem Schluss?
Kann (m)ein Multirail Netzteil die 12V für die CPU separat regeln? Falls ja, warum tritt das Problem (bislang) nur in Szenarien mit eher geringer Last auf (Dank damals negativem CO und relativ niedriger Last nur 30-60W PPT bei Hunt und RoN)?
 
Wie kommst du zu dem Schluss?
Kann (m)ein Multirail Netzteil die 12V für die CPU separat regeln? Falls ja, warum tritt das Problem (bislang) nur in Szenarien mit eher geringer Last auf (Dank damals negativem CO und relativ niedriger Last nur 30-60W PPT bei Hunt und RoN)?
12V ist die eine Seite. Ampere die andere. Oder zu starke Schwankungen? Bin da kein NT-Spezialist, aber man liest in den letzten beiden Jahren von gehäuften Problemen mit BQ-NTs. Was es so früher überhaupt nich gab.
Ist halt nur so ne Idee. Da Du ja sonst absolut fit in solchen Sachen bist, auch mal an die unwahrscheinlichen/ungewöhnlichen Dinge denken.
Gruß T.
 
Hab ja meinen nach dem Fall neuen 5900X auch übertaktet bevor ich nen X3D hatte.
Dabei merkt man relativ schnell, das hängt alles zusammen.

Habe ich die Kerne voll übertaktet war mein (sonst stabiler) IF nicht stabil.
Andersherum kann man einen leicht instabilen IF stabilisieren indem man etwas Kerntakt zurückfährt.

Daher denke ich es gibt da die verschiedensten Fälle und Probleme und viele Antworten können richtig sein.
Welcher WHEA wann kommt habe ich nicht drauf geachtet.
Hatte aber definitiv genau den hier:
"Gemeldet von Komponente: Prozessorkern
Fehlerquelle: Machine Check Exception
Fehlertyp: Bus/Interconnect Error"
 
12V ist die eine Seite. Ampere die andere. Oder zu starke Schwankungen? Bin da kein NT-Spezialist, aber man liest in den letzten beiden Jahren von gehäuften Problemen mit BQ-NTs. Was es so früher überhaupt nich gab.
Ist halt nur so ne Idee. Da Du ja sonst absolut fit in solchen Sachen bist, auch mal an die unwahrscheinlichen/ungewöhnlichen Dinge denken.
Gruß T.
Hast Recht, ja.
Beim Netzteil ist aber doch üblicherweise höhere Last ein Problem. Hunt und RoN sind (mit FPS Limiter) nicht so anspruchsvoll. Das Netzteil ist etwa nur zur Hälfte ausgelastet. Es wäre auch unwahrscheinlich, dass unter 16 Threads drei Mal der gleiche genau den gleichen Fehler verursacht.
Welche NT Serien bereiten denn gehäuft Probleme?

Hab ja meinen nach dem Fall neuen 5900X auch übertaktet bevor ich nen X3D hatte.
Dabei merkt man relativ schnell, das hängt alles zusammen.

Habe ich die Kerne voll übertaktet war mein (sonst stabiler) IF nicht stabil.
Andersherum kann man einen leicht instabilen IF stabilisieren indem man etwas Kerntakt zurückfährt.

Daher denke ich es gibt da die verschiedensten Fälle und Probleme und viele Antworten können richtig sein.
Welcher WHEA wann kommt habe ich nicht drauf geachtet.
Hatte aber definitiv genau den hier:
"Gemeldet von Komponente: Prozessorkern
Fehlerquelle: Machine Check Exception
Fehlertyp: Bus/Interconnect Error"
Ich tue mich etwas schwer meinen Fall darin wiederzufinden. Der Takt der 58X3D lässt sich nach oben nicht verändern. 1900 Mhz FCLK lagen seit über zwei Jahren an. Mir waren bis dato nie Probleme in der Hinsicht unter gekommen (keine WHEA Fehler, Audio Probleme oder etwas in der Art). Mir ist auch nicht bekannt, dass instabiler IF bei Halblast Probleme zeigt, aber bei höherer Last nicht.

Wo ich mir nicht ganz sicher bin, ist der Fehlertyp. Hier scheint es Meldungen bezüglich Cache zu geben und (wie bei mir/ uns) "Bus/Interconnect Fehler. Kann das die gleiche Ursache (VCore) sein? Das ergibt keinen Sinn, weil die durch den abgeschalteten CO nun höher liegt, der Fehler aber dennoch auftrat.

Hat jemand noch eine Idee für einen guten Test? Prime95 läuft nun seit knapp 17 Stunden ohne Fehler. Gefühlt tritt das Problem bei "höherem" Takt also leichterer Last eher oder ausschließlich auf.
 
Zuletzt bearbeitet:
Mach einen kompletten Stresstest vom ganzen System, läuft glaub ich ne Stunde. OCCT zeigt dir eine grafische Übersicht der Komponenten während des Tests an. Du kannst aber auch nur Cpu, Ram oder Graka testen. Du kannst auch glaub ich einstellen wann der Test aufgrund zb. hoher Temperaturen usw abgebrochen werden soll. Ich habs schon länger nicht mehr verwendet. Manuell kannst sowieso jederzeit abbrechen.

1745608027489.png
 
Nach stundenlangem rauf- und runtertesten mit Prime95 mit verschiedenen Einstellungen (1344K für VCore mit AVX2 und einen 20h Durchlauf von 8-4096K mit AVX), einer Stunde OCCT CPU Test mit AVX und variabler Last waren keine Fehler aufgetreten.
Daraufhin hab ich hinterfragt, in wie fern diese Tests das Problem überhaupt aufdecken können. Deswegen hatte ich meine OC Einstellungen wieder geladen, bis auf CO. Den hab ich statt der üblichen -30 auf -29 gestellt um einen seltenen Fehler, einen Freeze des Systems vermeintlich bei absolutem Idle und Monitor im Standby, der nur alle paar Monate mal auftrat, zu verhindern.
Interessanterweise hatte ich genau diesen Freeze nun trotz laufendem Prime nach etwa 30 Minuten. Nach dem im Eingangspost verlinkten Dokument kann eine zu hohe VDDG CCD Spannung dazu führen, dass der Grafiktreiber beim Start von Windows nicht geladen. Dies ist ein Fehler, den ich bei meinem System bereits seitdem ich das AM4 Board habe, beobachte, allerdings über 3 Grafikkarten und CPUs hinweg, aber alle mit IF OC.
Ich nahm immer an dieser Fehler hing mit meinem Fernseher zusammen (einziges Ausgabegerät neben einer beim Boot ausgeschalteten VR Brille) und wann ich diesen während des Bootvorgangs einschalte. Die Problem trat auch nur alle paar Monate mal auf.

Meine Theorie ist nun, dass zumindest der 5800X3D, aber möglicherweise auch die vorherigen CPUs, mit zu hoher VDDG IOD betrieben wurden. Weswegen diese nun von 0,950V um 10mV gesenkt habe. Ob das mit den WHEA 18 Fehlern zu tun hat, kann ich nicht sagen. Jedenfalls hat das System mit diesen Einstellungen nun über 20h verschiedene Prime95 Tests hinter sich gebracht, ohne Fehler.

Aufgrund der sporadischen Natur der Fehler, werde ich weiter testen. Aktuell läuft OCCT (CPU und RAM).
 
Zuletzt bearbeitet:
Hier ein Update zu dem Thema: Aufgrund der sporadischen Natur und den anderen Hinweisen, die online zu finden, habe ich (aus Verzweifelung) die CPU neu eingesetzt und die VCore für den fraglichen Kern 1 erhöht, indem der CO für diesen von -30 auf -28 erhöht wurde. Ich hatte in meiner Testreihe letzten Monat den CO komplett deaktiviert, vermutlich bin ich da aber einem (bekannten) BIOS Bug aufgesessen und der CO war nicht (richtig) deaktiviert, obwohl ich ihn auf 0 gesetzt und im gleichen Zug deaktiviert hatte.

Seit den Veränderungen von vor vier Wochen trat der Fehler jedenfalls nicht wieder auf, wobei sich mein Nutzungsprofil seitdem etwas geändert hat. Ich bin allerdings schon mal vorsichtig optimistisch, die Ursache gefunden zu haben, auch wenn es noch unklar ist, ob es eine Kontaktschwäche oder die Kernspannung war.
 
Zuletzt bearbeitet:
WHEA ID18 ist zu aggressives CO.
ID 19 wäre IF.

Etwas spät, aber das ist auch die Erklärung wieso du jetzt kein Problem mehr hast, es war eben das CO.

Die APIC-IDs zeigen auch den Thread an der abstürzt. APIC ID 2 wäre Core 1 Thread 0. ID3 entsprechend Core 1 Thread 1 und ID 4 Core 2 Thread 0, usw.

Für solche Tests (bis Zen 3) eigent sich der CoreCycler mit (richtig!) angepassten Configs, nicht die default Config.

Beachte auch, dass CO auch Nachbarkerne beeinflusst, also das reduzieren vom CO auf den beiden Nachbarkernen kann hier auch unterstützend wirken.
 
Zurück