Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: News des 1. Februar 2026
Leonidas
2026-02-02, 08:57:13
Link zur News:
https://www.3dcenter.org/news/news-des-1-februar-2026
Iscaran
2026-02-02, 09:54:10
In jedem Fall eiern die Mainboard-Hersteller nun schon seit Monaten an diesem Problem herum, während sich AMD diesbezüglich rar macht, obwohl dies eigentlich – da im groben alle Mainboard-Hersteller betroffen sind – zu allererst ein AMD-Problem darstellt. Sicherlich ist eine gewisse Defektrate normal, aber wenn sich die Probleme derart klar auf eine bestimmte CPU-Serie (Ryzen 9000) und dort primär ein Modell (Ryzen 7 9800X3D) konzentrieren, sollte sich AMD der Sache selber annehmen – was bis jetzt augenscheinlich nicht passiert ist.
So ein Schwachsinn! Es sind zum weit überwiegenden Teil AsRock mainboards (AFAIK >90%) der Fälle.
Der Rest verteilt sich auf ein paar einzelne CPUs hier und da, was einer relativ "normalen" Ausfallrate von CPUs entsprechen könnte.
Hier ist also zuvorderst AsRock als Mainboardhersteller in der Pflichtschuld - offenbar machen die irgendetwas anders als alle anderen Hersteller und da kann AMD wenig dafür.
Ich weiss zwar nicht wie aktuell die Zahlen aus dieser Reddit-Statistik sind:
https://www.reddit.com/r/ASRock/comments/1i5iy9a/update_and_summary_on_the_dead_9800x3ds/
Aber von den 157 reporteten CPU fails 9800X3D waren 130 Asrock, 20 ASUS, 5 MSI und 2 Gigabytye
Hier von "AMD 9800 X3D" sind fehlerhaft zu spekulieren und den "Fehler" hier AMD unterzuschieben ist bei dieser "Fallzahlenlage" äußerst merkwürdig.
Außer natürlich AsROCK ist praktisch der einzige Retailer der 9800X3D CPUs auf seinen Boards erlaubt.
EDIT: Und rein von den Verkausanteilen würde ich schätzen das ASRock hier auch noch am ehesten der Junior der 4 großen ist...also rein statistisch ist die Zahl an failenden ASUS-9800X3D CPUs viel niedriger als die auf ASROCK boards.
EDIT2: Auch im WCFTech artikel wird fast ausnahmslos von AsROCK boards berichtet...ist also ganz offenbar ein BOARD problem.
Leonidas
2026-02-02, 10:26:35
AMD könnte und sollte trotzdem reagieren. Der Fall köchelt inzwischen viel zu lange vor sich hin.
Iscaran
2026-02-02, 10:29:18
AMD könnte und sollte trotzdem reagieren. Der Fall köchelt inzwischen viel zu lange vor sich hin.
Und es sollte vor allem mal ASrock reagieren....warum nur fordert das keiner?!?;D
EDIT: ist scheinbar auch seit ca 6 Monaten hinlänglich dokumentiert, dass AsRock hier vor allem die SoC voltage viel höher wählt als alle anderen Motherboardhersteller.
https://www.igorslab.de/en/asrock-mainboards-show-noticeable-soc-voltage-fluctuations-risk-for-amd-ryzen-9000-cpus/
Warum?
ASUS und MSI haben reagiert:
https://hothardware.com/news/asus-9800x3d-failures-investigation
https://hothardware.com/news/ryzen-9800x3d-burned-chips
Ich sehe da auch kein "finger pointing" auf AMD....mag sein, das das noch kommt, aber die Faktenlage hierzu ist dünn.
EDIT2: Igor hat die SVI "Problematik" eigentlich recht schön ausgearbeitet.
https://www.igorslab.de/amds-skalierbare-spannungsschnittstelle-3-svi3-fuer-dummies-und-wie-man-ueberpruefen-kann-ob-das-am5-mainboard-sicher-ist/
IMHO setzt AsRock hier SVI3 nicht korrekt um, bzw. hat die Toleranzwerte zu "hoch" oder locker eingestellt. => Erhöhte Ausfallrate.
Die anderen Defekte sind ja faktor 5-10 "niedriger" bei anderen Herstellern und könnten daher durchaus im Rahmen "normaler" Ausfälle liegen.
Edit-Fazit: Asrock sollte endlich mal erläutern was sie bezüglich der hunderten Ausgefallener CPUs tun wollen...scheint ja immer noch, nach Monaten ein (nahezu) AsRock spezifisisches Problem zu sein.
Leonidas
2026-02-02, 12:00:12
ASRock hatte ja kürzlich wenigstens erklärt, dies zu untersuchen - insofern haben die die Forderung nach Wortmeldung bereits erfüllt Aber wird da etwas passieren, ohne Druck durch AMD?
downforze
2026-02-02, 12:54:50
Hat AsRock nicht bereits vor Monaten erklärt das zu untersuchen? Mir scheint die wollen es einfach nur totschweigen.
Iscaran
2026-02-02, 13:09:25
Hat AsRock nicht bereits vor Monaten erklärt das zu untersuchen? Mir scheint die wollen es einfach nur totschweigen.
Korrekt...das war im Mai und seitdem NICHTS.
Obwohl nach wie vor, FAKTISCH fast NUR CPUs auf AsRock-Boards ausgehen.
Aber ist natürlich AMD's Schuld, dass sie einem OEM da nicht mehr die Leviten lesen. Gott bewahre und man hätte einen Dysfunktionalen 12V Stecker verkauft...der Shitstorm wäre nicht auszumalen.
Semmel
2026-02-02, 13:11:18
Ich habe schon einige AM5-Boards von Asrock in Betrieb genommen und mir ist überall aufgefallen, dass das Board automatisch diverse Spannungen raufstellt, wenn man ein EXPO-Profil lädt oder manuelles RAM-OC betreibt. Da steigt schon das Risiko, dass der IOD gegrillt wird. Ich habe die Einstellungen daher wieder von Hand runtergestellt.
Ich glaube Asrock hat hier auch schon sicherere Einstellungen im aktuellen BIOS nachgeliefert. Mit der Version 4.03, die ich vor kurzem drauf gemacht habe, geht die VDDCR_SOC auch mit RAM-OC nur noch bis 1,20 V. Aber das muss sich auch erst verbreiten.
Ich habe schon einige AM5-Boards von Asrock in Betrieb genommen und mir ist überall aufgefallen, dass das Board automatisch diverse Spannungen raufstellt, wenn man ein EXPO-Profil lädt oder manuelles RAM-OC betreibt.
Das macht jedes Board.
Lehdro
2026-02-02, 15:10:46
Ich habe schon einige AM5-Boards von Asrock in Betrieb genommen und mir ist überall aufgefallen, dass das Board automatisch diverse Spannungen raufstellt, wenn man ein EXPO-Profil lädt oder manuelles RAM-OC betreibt. Da steigt schon das Risiko, dass der IOD gegrillt wird. Ich habe die Einstellungen daher wieder von Hand runtergestellt.
Sollte man sowieso immer machen, tun aber leider nur die wenigsten. Wichtige Spannungen immer manuell festzurren!
Ich glaube Asrock hat hier auch schon sicherere Einstellungen im aktuellen BIOS nachgeliefert. Mit der Version 4.03, die ich vor kurzem drauf gemacht habe, geht die VDDCR_SOC auch mit RAM-OC nur noch bis 1,20 V. Aber das muss sich auch erst verbreiten.
Das SoC Problem hat ASRock doch schon vor zig UEFIs gefixt, gebracht hat es nichts. 3.25 fing an die TDC/EDC Limits vernünftig zu setzen und PBO einzudampfen auf AMD Werte, (was das angebliche Problem war). Der "letzte finale Fix" (tm) hat nun wohl noch einmal Sachen bereinigt, die eigentlich schon in 3.40 (SoC = 1.2V, LLC Level 3) im September 2025(!) behoben sein sollten.
Blöd nur das weiter CPUs starben, sowohl mit als auch ohne PBO, so wohl mit als auch ohne EXPO...
Blöd nur das weiter CPUs starben, sowohl mit als auch ohne PBO, so wohl mit als auch ohne EXPO...
Es könnte sich dabei aber auch um CPUs handeln die entsprechend vorgeschädigt sind.
crnkoj
2026-02-02, 16:58:17
Sollte man sowieso immer machen, tun aber leider nur die wenigsten. Wichtige Spannungen immer manuell festzurren!
Das SoC Problem hat ASRock doch schon vor zig UEFIs gefixt, gebracht hat es nichts. 3.25 fing an die TDC/EDC Limits vernünftig zu setzen und PBO einzudampfen auf AMD Werte, (was das angebliche Problem war). Der "letzte finale Fix" (tm) hat nun wohl noch einmal Sachen bereinigt, die eigentlich schon in 3.40 (SoC = 1.2V, LLC Level 3) im September 2025(!) behoben sein sollten.
Blöd nur das weiter CPUs starben, sowohl mit als auch ohne PBO, so wohl mit als auch ohne EXPO...
Auch bei Intel sitndas ein Problem mit xmp, dass einfsch allé Spannungen durchweg erhot werden, ohne Grund und ohne Bedarf.
Auch bei Intel sitndas ein Problem mit xmp, dass einfsch allé Spannungen durchweg erhot werden, ohne Grund und ohne Bedarf.
Das ist der Sinn der Sache. XMP/EXPO ist nichts anderes als pretested OC mit entsprechend hinterlegten Spannungen, Frequenzen und Latenzen.
Hochzeit2
2026-02-02, 18:29:14
Den Müll von Reddit als Referenz zu nehmen das es bestimmte Probleme gibt ist lächerlich.
Erst recht, wenn nur 1 der Personen einen Nachweis gepostet hat, das die CPU überhaupt eingeschickt wurde.
crnkoj
2026-02-02, 19:36:19
Das ist der Sinn der Sache. XMP/EXPO ist nichts anderes als pretested OC mit entsprechend hinterlegten Spannungen, Frequenzen und Latenzen.
Ja und nein.
Der Sinn ist, dass es OC, stabil und safe ist
Was anscheinend hier bei asrock nicht klappt und auch die raptor lake Probleme sind oft auch durch xmp erst entstanden.
Ja und nein.
Der Sinn ist, dass es OC, stabil und safe ist
Was anscheinend hier bei asrock nicht klappt und auch die raptor lake Probleme sind oft auch durch xmp erst entstanden.
Dann ist die Frage, geht AsRock über die von AMD empfohlenen Limits, oder hat AMD ihnen Limits mitgeteilt die in Wirklichkeit nicht Safe sind.
Ätznatron
2026-02-02, 22:00:35
Dann ist die Frage, geht AsRock über die von AMD empfohlenen Limits, oder hat AMD ihnen Limits mitgeteilt die in Wirklichkeit nicht Safe sind.
Ja genau, AMD sabotiert gezielt Asrock, während die anderen Hersteller korrekte Limits erhalten. :freak:
Leonidas
2026-02-03, 02:35:30
Aber ist natürlich AMD's Schuld ...
Nein, das war nicht meine Aussage und das will ich auch nicht aussagen. Ich sagte, AMD soll sich drum kümmern - eben weil es ASRock faktisch nur totschweigt (oder sonstwie nicht hinbekommt).
Ja genau, AMD sabotiert gezielt Asrock, während die anderen Hersteller korrekte Limits erhalten. :freak:
Was für eine dumme Aussage.
AMD gibt den Mainboardherstellern Limits vor. Wie weit diese an diese Limits gehen ist deren Sache.
Die Mainboardhersteller testen dann die Speicherkits für ihre QVL-Listen und geben dann noch etwas an Sicherheitsmarge drauf, das was man am wenigsten will ist schließlich ein Kunde der sich über ein instabiles System beschwert.
Man kann auch weniger Aufwand in diese Tests stecken und dafür eine höhere Sicherheitsmarge einrechnen. Das einzige was der Kunde merken sollte ist dann ein etwas höherer Verbrauch, was im DIY-Markt allerdings kaum jemanden interessiert, warum sollte der dann überhaupt XMP/EXPO nutzen?
Wenn man immer noch in den von AMD vorgegebenen Limits bleibt sollte damit alles OK sein.
Die Frage ist also, verwendet ASRock einfach eine höhere Sicherheitsmarge innerhalb der von AMD vorgegebenen Limits --> AMD ist schuld.
Ignoriert ASRock bewusst die AMD-Limits für höhere Stabilität --> ASRock ist schuld.
Da die von AMD an die Mainboardhersteller kommunizierten Limits nicht Teil öffentlicher Diskussion sind kann man das von Außen nicht beurteilen.
vBulletin®, Copyright ©2000-2026, Jelsoft Enterprises Ltd.