Ryzen 5000 Whea Fehler (inklusive Reboot) was tun....

Nein, hatte bisher null WHEA/Reboot mit einer 5700XT und z.b. HW Info 6.42.
Tjoa, dann bist du der einzige den ich da kenne.
Die Kollegen hatten mitunter nicht mal eine Radeon drin und das Problem... :confused:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Holzmann
Ich meinte auch damit das bei mir die 2702 die letzte ist die bei mir Fehlerfrei funktioniert.
 
Ja der Einzige - is klar. Denke die Diskussion führt zu nix - ich kenne genug ohne WHEA Fehler. Und wir reden von HW Info veranlassten Fehlern. Es können ja auch genug aus anderen Gründen auftreten - auch auf Intelsystemen. Man sollte schon differenzieren.
 
So ich wollte mich auch nochmal zurückmelden.

Habe durch den RMA Prozess meinen neuen 5900X bekommen. Seit dem Einbau kein einziger WHEA Error im Event Log und es treten keine Bluescreens mehr auf. Kann auch im BIOS munter overclocken/underclocken ohne dass danach diese Fehler auftreten. Bin also echt glücklich mit der CPU, auch wenn der Weg dahin etwas stolprig war.
 
Kann ich nur bestätigen, völliger Schwachsinn von @Pirate85. UEFI Default Settings & sogar nur 2133 MHz RAM haben bei meinem ersten 5950X trotzdem zu haufenweise WHEA ID 19 (ca. jede 3 Sekunden) und des Öfteren ID 18 und anderen Reboots geführt. Nach einer Woche ist der 5950X jedes Mal beim Boot abgestürzt, außer wenn ich CPB, also den "Turbo" ausgeschalten hab.

Austausch 5950X (übrigens nur eine Woche später produziert) funktioniert problemlos. Keinen einzigen Reboot, Bluescreen etc. mehr. Ein paar WHEA ID 19 Fehler hatte ich noch pro Tag, wenn ich den IF/RAM auf 1800/3600 oder höher laufen lassen hatte, aber das konnte durch folgende Settings beheben:
 
Joa, völliger Schwachsinn. :bigok:

Hier ist ne "Handvoll" Leute mit Problemen wo es durch Austausch erledigt war - und diese denken sie sind der Nabel der Welt. GZ

Bei den allermeisten sind es AGESA Probleme und keine kaputten oder falsch gebinnten Chips, sonst gäbe es nämlich richtig Shitstorm gg AMD, aber labert mal schön weiter und bezichtigt andere der Märchen oder des Schwachsinns - macht nen guten. :wink:


Ich kann nur sagen das es hier keinen einzigen "defekten" Chip in dem Sinne gab, und das sind mehr als ein Dutzend CPUs durch alle Klassen, entweder die liefen mit Stock Settings + erhöhter SoC Voltage oder sie liefen mit nem AGESA Update.

Die wo es komplett in die Hose gegangen ist tun mir leid, solange der Austauschchip funzt gehts ja noch... sollte man [leider] ja mittlerweile bei den RyZens gewohnt sein das die nicht vom Start weg gut laufen.
 
Joa, völliger Schwachsinn. :bigok:

Hier ist ne "Handvoll" Leute mit Problemen wo es durch Austausch erledigt war - und diese denken sie sind der Nabel der Welt. GZ
Komm, übertreib mal nicht... Die Leute sind hier angepisst, weil ihre teuer erkauften Systeme nicht laufen. Nicht mehr und nicht weniger. Den Nabel der Welt dichtest du hier dazu... Davon war nie die rede! Warum fühlst du dich direkt getriggert? Auch das "läuft @Stock" Argument, stimmt halt so nicht. Ob es jetzt Agesa Code ist, der das Problem verursacht oder nicht, ist dabei nichtmal von belang. Denn so wie es sich bis dato zeigt muss ein Zusammenhang mit dem Prozessor selbst bestehen. Sonst würde der Tausch der CPU bei gleichem Rest das Problem nicht beseitigen. Vielleicht wurde das Zeug auch einfach nur auf Brechgrenze gebinnt um die eh maue Liefermenge hoch zu treiben, vllt gab es Chargenweise Probleme, vllt was ganz anderes... Keiner weis es im detail. Aber deswegen muss man doch nicht das Argument um 180 Grad ins Gegenteil drehen... Auch der Wink - Ryzen läuft zum Start immer scheiße - mMn genau so unnötig. Sollen sie ihren Mist halt anständig bauen, dann gibts auch keine Kritik. Schaffen sie es nicht, gibts halt Kritik. Fertig...
 
Wie viele so tun als wäre nur AMD daran schuld. :fresse:

JEDES System was hier bisher das Problem hatte läuft @Stock... d.h. UEFI Default Settings & MAXIMAL 3200Mhz aufm RAM... Wer mehr will bekommt WHEAs solange das Problem nicht behoben ist.

Ich kann nur sagen das es hier keinen einzigen "defekten" Chip in dem Sinne gab, und das sind mehr als ein Dutzend CPUs durch alle Klassen, entweder die liefen mit Stock Settings + erhöhter SoC Voltage oder sie liefen mit nem AGESA Update.
Ich würde dir empfehlen, deine Beiträge deutlicher zu schreiben. Du schreibt erst etwas allgemeines und sagst dann "hier", was man leicht als hier im Thread interpretieren kann.
Mit dem zweiten Beitrag wird es klarer, dass du mit "hier" wohl ?einige selbstgebaute Systeme? meinst. Also deine persönliche Erfahrung.

Klang halt so, als ob du sagen willst, dass bei jedem System das Problem davor sitzt und es niemals an einem defekten Prozessoren liegt...
 
Danke, so sollte das nicht rüber kommen. :shake:

Ja, ich meine selbst gebaute Systeme - Glücklicherweise bin ich bzw sind wir bis auf die angesprochenen WHEA Fehler aufgrund der ersten AGESA Versionen und der RAM Kompatibilität gut durch den Start durchgekommen.

Selbst die Systeme die WHEA Fehler hatten konnte man bis zum entsprechenden AGESA Update über ein anheben der SoC Spannung stabilisieren (~1,0875V +-0,025V für 3200Mhz, ab 3600Mhz waren mitunter schon 1,15V +-0,025V nötig... daher habe ich irgendwie so meine Zweifel an der Aussage AMDs das der IO Chip derselbe ist. Bei keinem 3000er RyZen habe ich auch nur annähernd so viel Spannung gebraucht).

Das waren, bis ich Anfang Januar meine letzten Aufträge durchgeballert habe, 15 Systeme mit RyZen Plattformen und alles über 5600X (waren lediglich 2 mit 5600X) hat ganz am Anfang entsprechende Probleme gemacht.
 
Zuletzt bearbeitet:
Für 1900+ muss ich bei meinem auf knapp 1,18V Vsoc gehen. Daher fahre ich momentan nur 3600 (und CL18 weil nur 1,35V - ich habe leider nur Low binned Micron B-Die da, da ich noch auf mein VLP Kit aus China warte und das LPX quasi mein Backup Kit ist) und hoffe das ASRock endlich mal mit der neuen AGESA ausm Arsch kommt... ich hab noch die 1.1.0.0 patch C :wall:

Deswegen schiebe ich das nicht unbedingt auf AMD, die machen schon ordentlich Ballett mit neuen AGESA um das in den Griff zu kriegen, aber ASRock kommt absolut nicht hinterher momentan - zumindest bei den ITX Boards.

Hatte schon überlegt mal das MSI B550er ITX zu testen deswegen (Die sind wie ASUS verdammt schnell mit neuen Versionen), aber das wäre im Endeffekt Geldverbrennung.
 
Zuletzt bearbeitet:
Bei den allermeisten sind es AGESA Probleme und keine kaputten oder falsch gebinnten Chips, sonst gäbe es nämlich richtig Shitstorm gg AMD, aber labert mal schön weiter und bezichtigt andere der Märchen oder des
Kann ich so unterschreiben ab AGESA V2 PI 1.1.9.0. waren die WEHA Fehler verschwunden.
 
So. Nach dem letzten idle-Reboot am 30.01.2021 nun heute nach ca. 2 Wochen wieder erneut. Selbstverständlich die gleiche Leier mit WHEA ID18.
Habe jetzt die CPU NB/SoC Voltage auf 1,15V gesetzt und werde berichten.

3700X, X570 MEG Unify, 2x16Gig TridentZ 3600 / IF 1800 - Rest Stock.

Ps. Ich habe den Eindruck, dass hier viele denken, nur die Ryzen 5000er wären betroffen. Dem ist aber nicht so, das Problem gibt es schon massiv seit 3000.
 
Kann ich so unterschreiben ab AGESA V2 PI 1.1.9.0. waren die WEHA Fehler verschwunden.
Da aber keiner der Leute, die ihre CPU per RMA bei AMD getauscht hat, jemals die neue Agesa Version testen kann - ist das argumentativ auch nicht wirklich belastbar.
Natürlich lässt sich via Agesa da was nachjustieren - wäre ja nicht das erste mal, die Frage ist eher, was genau und wie?
Das hat irgendwie den gleichen Touch von NV mit ihren 3000er RTX Karten und den Takt-Problemen zu Anfang - bis der Treiber da bisschen Wind raus genommen hat um das stabil zu bekommen. Riecht mir primär nach einem Mittelding. Vielleicht haben sie einfach hier und dort Stellschrauben angepasst um das Problem bisschen zu umgehen, weil Modelle im Umlauf davon betroffen sind/waren und man merkte, dass es zu RMAs kommt. Vllt auch nicht. Am Ende kann man es nicht belegen...

Ich sehe allerdings nach wie vor nen Unterschied zwischen den Fehlern, die bei OC entstehen und wo die Leute einfach ihre Settings obenraus nciht stabil bekommen und denen, die Stock und absolut ohne jeden Spezifikationsübertritt auftreten. Ersteres ist schade, aber shit happens - letzteres sollte so einfach nicht sein.

Ps. Ich habe den Eindruck, dass hier viele denken, nur die Ryzen 5000er wären betroffen. Dem ist aber nicht so, das Problem gibt es schon massiv seit 3000.
Nicht "das" Problem - es gibt viele Ansätze. Du betreibst OC. Das ist ne ganz andere Nummer als das, was bspw. der TE hatte, als dieser Thread hier erstellt wurde. Denn da ging es um Stabilität out of the box ohne jegliche OC Werte oder Anpassungen. Selbst mit 2400er Speichertakt und damit unter Spezifikation ging nicht anständig.

Es wäre ehrlich wünschenswert, wenn man das nicht immer mischen würde... Nur weil die Fehler ID im Log die gleiche ist. Das Log beschreibt lediglich das Resultat. In dem Fall, ein gemeldeter Fehler im Cache.
 
Mir ist klar, dass man die Szenarien differenzieren sollte. Allerdings habe ich das Problem auch mit Stock-Settings (also XMP off, Rest ebenfalls Stock). Mir ist auch klar, dass die Fehlerquelle trotz gleicher Fehler unterschiedlich sein kann.
Allerdings können wir - egal wie differenziert man das betrachtet - den sogenannten "idle-Reboot" durchaus eingrenzen und als "..das Problem" bezeichnen, wenngleich es auch mehrere Varianten davon gibt.

Ein System, dass selbst unter extremer Last bombenstabil läuft, jedoch im idle abstürzt bzw. ohne dumpfile rebootet ist ein ganz klar definierbares Problem und ist genau das, wovon der TE hier auch betroffen ist/war.
Dass sich dann noch viele andere hier eingeklinkt haben, bei denen die Reboots unter anderen Szenarien auftauchen ist da nochmals ne andere Sache.

Da ich dann noch im Laufe der Beiträge viel Kritik über die Ryzen 5000er gelesen habe, wollte ich nur nochmal anmerken, dass Besitzer eines Ryzen 3000 mit den selben Problemen kämpfen.
 
So. Nach dem letzten idle-Reboot am 30.01.2021 nun heute nach ca. 2 Wochen wieder erneut. Selbstverständlich die gleiche Leier mit WHEA ID18.
Habe jetzt die CPU NB/SoC Voltage auf 1,15V gesetzt und werde berichten.

3700X, X570 MEG Unify, 2x16Gig TridentZ 3600 / IF 1800 - Rest Stock.

Ps. Ich habe den Eindruck, dass hier viele denken, nur die Ryzen 5000er wären betroffen. Dem ist aber nicht so, das Problem gibt es schon massiv seit 3000.
Gleiches bei mir. Heute morgen einen Idle Reboot gehabt, nachdem es zuvor zwei Wochen stabil lief.

Bei Gigabyte gibt es für mein Board auch keine stabile Bios Version mit AGESA 1.2.0.0, nur irgendwelche im tweaktownforum geposteten Alpha Versionen, die tausend andere bugs haben.
 
Da aber keiner der Leute, die ihre CPU per RMA bei AMD getauscht hat, jemals die neue Agesa Version testen kann - ist das argumentativ auch nicht wirklich belastbar.
Natürlich lässt sich via Agesa da was nachjustieren - wäre ja nicht das erste mal, die Frage ist eher, was genau und wie?

Dafür müsse man schon bei AMD arbeiten, schätze dann werden viele deiner Fragen eine Antwort finden. Am Ende ist es auch Wurst wenn am Ende ein BIOS Update mit neurer AGESA das Problem behebt ist doch alles okay. Bier aufmachen , einen Schluck trinken und sich freuen.
Beitrag automatisch zusammengeführt:

Bei Gigabyte gibt es für mein Board auch keine stabile Bios Version mit AGESA 1.2.0.0, nur irgendwelche im tweaktownforum geposteten Alpha Versionen, die tausend andere bugs haben.

Ja von Alpha und Beta Versionen mache ich auch einen Bogen. Keine Lust und Zeit als Testkaninchen rumzueiern und Probleme zu melden
 
@Pirate85

Im Overclock.net Forum und auch im AMD Forum sind auch schon mehrere Leute die nach der RMA keine Probleme mehr hatten.


Finde ich ein bissl überheblich, das man hier den Leuten vorwirft das diese selbst dran schuld sind.

Eine neue CPU hat mit AMD Spezifikationen out of the Box zu laufen und das hat meine 5950X damals nicht auf meinem C8H mit Bios 3204.

Erst mit einer RMA CPU lief das System dann und ich habe dazwischen nichts verändert.

Und solange es keine grosse Welle gibt und z.B. Printmedien darüber berichten wird AMD sich still verhalten und hoffen das

nicht soviele CPU´s betroffen sind. Ich gehe sogar davon aus das AMD weiss welche CPU´s genau diesen Fehler verursachen.

Oder wie geklärst du dir das, das meine RMA Anfrage innerhalb von 3 Std. durch war ? Normalerweise fragen die dann noch ob man

selbst probiert hat den Fehler zu lokalisieren. AMD wollte nur ein Foto von der defekten CPU im Sockel und 3 Std. später hatte ich mein

DHL Express Etikett.
 
Zuletzt bearbeitet:
Es wäre ehrlich wünschenswert, wenn man das nicht immer mischen würde
so ist es. Nur ist bei AMD Spezifikationstechnisch alles ein wenig schwammig formuliert.

Beispiel: ZEN3 - FCLK 1600 - Man kauft sich ein kompatibles RAM KIT und das darin hinterlegte XMP/DOCP Profil passt nicht zu diesen Spezifikationen. Dafür habe ich kein Verständnis weil AMD diese selbst definiert hat.
Klar masochistisch veranlagte Leute fummeln solange an den Timings oder BIOS Einstellungen rum bis es augenscheinlich stabil funktioniert und keine WHEA Fehler mehr im Ereignisprotokoll auftauchen.

Die Mehrheit möchte sich so etwas sicherlich ersparen und einfach nur ein System haben im Rahmen der Spezifikationen stabil läuft -mit dem Bonus das genug OC Reserven vorhanden sind-
 
@Pirate85

Im Overclock.net Forum und auch im AMD Forum sind auch schon mehrere Leute die nach der RMA keine Probleme mehr hatten.


Finde ich ein bissl überheblich, das man hier den Leuten vorwirft das diese selbst dran schuld sind.

Eine neue CPU hat mit AMD Spezifikationen out of the Box zu laufen und das hat meine 5950X damals nicht auf meinem C8H mit Bios 3204.

Erst mit einer RMA CPU lief das System dann und ich habe dazwischen nichts verändert.

Und solange es keine grosse Welle gibt und z.B. Printmedien darüber berichten wird AMD sich still verhalten und hoffen das

nicht soviele CPU´s betroffen sind. Ich gehe sogar davon aus das AMD weiss welche CPU´s genau diesen Fehler verursachen.

Oder wie geklärst du dir das, das meine RMA Anfrage innerhalb von 3 Std. durch war ? Normalerweise fragen die dann noch ob man

selbst probiert hat den Fehler zu lokalisieren. AMD wollte nur ein Foto von der defekten CPU im Sockel und 3 Std. später hatte ich mein

DHL Express Etikett.

Natürlich, sowas ist Service und wenn bekannt ist das nicht jede Config überall läuft und es Probleme mit den CPUs gibt ist es nur selbstverständlich dass das so abläuft.
Ist doch top wenn das dann so schnell geht? :confused:

Man muss immer bedenken: Wir Leute in den Foren sind nur nen gaaaaaaanz kleiner Prozentsatz die sich so hart mit der Materie auseinander setzen und die überhaupt versuchen z.b. so ne CPU zu übertakten... der Otto Normalverbraucher da draußen macht entsprechendes nicht.

Leider habe ich nicht viele Leute bei uns mit OEM Systemen in denen entsprechende CPUs laufen um nen Urteil bilden zu können ob das Problem bei OEM / AiB Systemen auch vorhanden ist.
 
Zuletzt bearbeitet:
In den Foren sind auch Leute die das Problem bei Fertig PC´s haben bzw. hatten.
Die meisten werde das System wohl umtauschen, wenn es instabil ist.
Deswegen liest man nicht viel darüber.
 
Ich hab eine neuen 5800x aus 2105 der Läuft ohne WHEAs - gleiche Windows Installation. Alles auf default.
 
So. Nach dem letzten idle-Reboot am 30.01.2021 nun heute nach ca. 2 Wochen wieder erneut. Selbstverständlich die gleiche Leier mit WHEA ID18.
Habe jetzt die CPU NB/SoC Voltage auf 1,15V gesetzt und werde berichten.

3700X, X570 MEG Unify, 2x16Gig TridentZ 3600 / IF 1800 - Rest Stock.

Ps. Ich habe den Eindruck, dass hier viele denken, nur die Ryzen 5000er wären betroffen. Dem ist aber nicht so, das Problem gibt es schon massiv seit 3000.
Update: Heute wieder 2x idle Reboots gehabt. Das Anheben der SoC Spannung auf 1,15V hat also leider nichts gebracht. Eine weitere Erhöhung hat bei mir zu massivem Ruckeln/Stottern in YouTube Videos geführt.
Momentan sind wieder alle Spannungen auf Auto eingestellt, jedoch der RAM Takt auf 3400 bzw. 1700MHz herabgesetzt, so auch der IF-Takt.
werde dann weiter berichten.
 
Diese frickelei bringt überhaupt nichts.... Wenn die CPU @ Stock auch nicht stabil läuft, also Speicher auf 2400 und IF auf 1200 mhz dann ist die CPU defekt !

Was du machen kannst, da du einen Matisse hast, ein Bios VOR Ryzen 5000 kompatibilität zu nutzen. Also alles zwischen Agesa 1.0.0.0 und Agesa 1.0.8.0.
 
Zuletzt bearbeitet:
Diese frickelei bringt überhaupt nichts.... Wenn die CPU @ Stock auch nicht stabil läuft, also Speicher auf 2400 und IF auf 1200 mhz dann ist die CPU defekt !

Was du machen kannst, da du einen Matisse hast, ein Bios VOR Ryzen 5000 kompatibilität zu nutzen. Also alles zwischen Agesa 1.0.0.0 und Agesa 1.0.8.0.
Hatte ich schon. Das Problem bestand bei mir auch schon mit beispielsweise Agesa 1002.
Was die Frickelei bezüglich Ram-Takt angeht gebe ich dir aber recht, das ergibt keinen Sinn. Keine Ahnung, warum ich die Tatsache, dass es auch mit Stock-Settings abstürzt jetzt ignoriert habe.

Aber ich gebe noch nicht auf.
RAM ist nun wieder gemäß XMP auf 3600. Umgestellt habe ich nun (Tipp aus den vorigen Kommentaren):
VDDG CCD auf 925mV
VDDG IOD auf 1025mV
 
Seit gestern habe ich Docker Desktop unter Windows 10 installiert und gerade hatte ich beim Arbeiten eine neue Variante von Bluescreen:
Stillstandscode: HYPERVISOR_ERROR
Dumpfile wurde geschrieben, wird aber nur der Windows Kernel als Fehlerquelle angezeigt. Im Eventlog steht nur der Reboot als Fehler, sonst keine weiteren Hinweise.

Keine Ahnung, ob die Virtualisierungsfunktionen bei Ryzen 5000 und zugehörigen BIOSen noch nicht ausgereift sind, oder ob das ein Fehler in der Docker Software war und das Ding auf jeder CPU abgeschmiert wäre.
Parallel arbeite ich auch noch mit VMWare Player 16 und das lief bisher stabil.

Hat jemand hier schon irgendwelche Erfahrungen wie sich die Ryzens hinsichtlich Virtualisrieung verhalten und ob das eine Bluesreen Fehlerquelle ist.
 
Finde ich ein bissl überheblich, das man hier den Leuten vorwirft das diese selbst dran schuld sind.

Willkommen in der roten Blase. Regel Nr. 1 - Wenn´s nicht laeuft, ist Intel oder Nvidia schuld. Ist diese These nicht aufrechtzuerhalten, greift Regel Nr. 2 - der Anwender ist zu low fuer Hardware von AMD. Ist auch das durch Fakten widerlegt, wie z. B. hier durch RMAs, dann kommt Regel Nr. 3 ins Spiel - seht nur, wie toll der Support von AMD ist.

Und die Moral von der Geschicht? Auch defekte Chips stoeren den Hardcore-Fan nicht. AMD kann machen, was immer man machen will. Preise erhoehen, defekte Hardware ausliefern - die Groupies klatschen trotzdem. Ich habe es aufgegeben, nach dem Sinn dahinter zu suchen und mich stattdessen damit abgefunden, dass es eben keinen gibt.
 
Top Kommentar :bigok:


AMD bekommt für defekte CPUs genauso aufm Sack wie Intel für WLP-TIM unter der Mütze, AMD bekommt für bescheidene Treiber genauso aufm Sack wie nVidia für ihre Speicherknausrigkeit oder ihren Optimierungswahn der manchmal ältere GPUs die Leistung kostet.

Ist völlig Latte... man muss aber auch mal die Kirche im Dorf lassen können und alles nicht übertreiben - DAS ist nen Problem mmn.
Scheiße wenns einen erwischt, aber hier klingt es immer so als wäre jede 2. CPU defekt. :confused:


Ich hab gestern nen defekten TP-Link Archer VR600v bekommen... letztes Jahr auch schon einen... ja mein Gott, das passiert leider.
Mit AVM wäre einem das nicht passiert gelle? :fresse: (Ups, meine 7350 hatte auch schon einen Defekt) ...


Ist dass das einzige was die Deutschen noch können? Rumheulen? Irgendwie kommts mir langsam so vor. :shake:
Austauschen lassen und fertig ist die Laube, hoffentlich lernt AMD draus.

Bei den Treibern hats ja soweit geklappt von RX 5700 Reihe zu RX 6800 Reihe... wenn ich dran denke was es anfangs mit der 5700er Reihe für Probleme gab, die 6800 läuft bislang ohne jedes Problem... genauso wie die 3070.

 

Anhänge

  • IMG_20201125_165535990 (1).jpg
    IMG_20201125_165535990 (1).jpg
    469,2 KB · Aufrufe: 73
  • IMG_20201201_163747143_HDR.jpg
    IMG_20201201_163747143_HDR.jpg
    876,4 KB · Aufrufe: 77
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