Ryzen 9000: AMD sieht Mainboard-Partner bei AM5-Socket-Burnouts in der Pflicht

Problem scheint ja auch mal wieder eine peakende SOC-Voltage zu sein und der verträgt eben leider nicht wirklich viel.

Ja, hätt ich noch meinen ersten 98X3D samt Rechnung, wäre ich etwas entspannter. Aber ich hab einen gebinnten, sprich 2nd Hand, da grausts mir schon latent, auch wenn ich vom Erstbesitzer die Rechnung hätte, die mir im Fall aber nichts hilft. Daher hab ich aktuellen 98X3D auch bislang noch nicht beim PBO optimiert - und was der in CineBench schafft, hab ich keine Ahnung.

Anders beim Zweitrechner (7950X auf einem der grausigen B650 MSI), den hab ich in üblen Allcore-Spannungs-Orgien schon ein paarmal in CineBench ausgeknipst und mich fast gewundert, dass er wieder gebootet hat. Oder anders gesagt, die Ryzen können normal schon echt was wegstecken. Diese Sache bei ASRock+X3D ist da halt einfach ganz etwas ungewohntes.

Eher nicht. Einzelne Probleme tauchen immer mal wieder auf und dann hängt es von realen oder vermeintlichen Mustern ab, wie hoch die Sache kocht. Ich erinnere an den Sockel 1156. Neu ist nur, dass es mal AMD trifft – da die in den bisherigen Shitstorms aktivste Meute aber nie einen Fehler bei AMD sehen würde, ist es diesmal schwerer, mit dem Finger zu zeigen. Asrock kriegt zwar viel Flak ab, weil das Problem zuerst in /r/Asrock/ thematisiert wurde und dort, oh welch Wunder!, vergleichsweise wenig Biostar- und ECS-User ihre Probleme klagen, weswegen auch viele News konzentriert über Asrock berichten. Aber da es halt auch sehr viele überzeugte Asrock-Nutzer gibt, gerade auch im AMD-Lager, und die überwältigende Mehrheit keinerlei Probleme feststellen kann, köchelt das ganze nicht über, sondern auf Sparflamme.

Wie schon bei den RPL-Problemen sind leider auch diesmal die meisten Fälle nur oberflächlich dokumentiert. Oft sind nicht einmal alle Einstellungen bekannt und hat natürlich hat niemand, bevor es zu spät war, einen Grund gehabt, konkrete Parameter im Betrieb zu prüfen. Das macht es schwer, die tatsächliche technische Ursache zu ermitteln und Gegenmaßnahmen oder begründete Schuldzuweisungen zu nennen.

Wenn es die geben sollte, sind sie wirklich sehr unbekannt.
Eigentlich gilt die Ansteuerung von Ryzen-CPUs als fest in der Hand von AMD. Mainboard-Hersteller können PBO freigeben, wo das erlaubt ist, und sie können durch niedrigere Plattformlimits bremsen. Aber alles andere macht AGESA. Die einzige bekannte Werks-OC-Methode ist eine Manipulation der Eingangsgrößen: Keine CPU kann ihre eigene Stromaufnahme messen. Die dafür nötigen Daten werden von den Spannungswandlern des Mainboards bezogen und wenn dieses einen zu niedrigen Wert meldet, wird eine zu niedrige Verlustleistung ermittelt, sodass die CPU sich länger innerhalb der Power Limits wähnt als sie es tatsächlich ist. Die letzten bekanntgewordenen Fälle, in denen das ausgenutzt wurde, waren aber zu mittleren AM4-Zeiten und bewegten sich in typischen, also eher harmlosen OC-Dimensionen. Seitdem ist nichts mehr aufgefallen und ich überwache in Mainboard-Tests sowohl den Systemverbrauch mit externen Methoden als auch die resultierenden Taktraten und Temperaturen. Wenn jemand bei angeblichen "180 W" auf einmal Takt, Verbrauch und resultierende Temperaturen einer gefährlichen 280-W-OC-Konfiguration anliegen würden, würde das sofort auffallen.

Ich denke AMD wird den Ball flach halten und defekte CPUs still tauschen, wie bei Ryzen 1 und dem Segfault Bug. Eigentlich wäre mir natürlich eine umfassende Aufklärung lieber, da Daves Aussage über die dynamische SoC-Spannung auch möglich wäre.
Damals hatte ich einen gebrauchten Ryzen 1600 günstig ersteigert und gegen einen neuen umgetauscht.

Ich bin erstmal froh durch meine Probierfreudigkeit ein Mainboard von Gigabyte statt ASRock zu haben, stelle die SoC-Spannung aber sowieso manuell auf einen festen Wert.

Richtig. Aber nur, weil AMD offenbar diese Funktion nicht richtig getestet hat. Dafür können logischerweise Asrock, Asus und Co. nichts, denn diesen Modus gibts schon ewig und drei Tage in sämtlichen AGESAs.