Hat jemand einen Ryzen (AM4) welcher ab der 25. Kalenderwoche produziert wurde?

[DEFCON2]

Fehler in allen aktuellen Intel-CPUs kann zu Datenverlust führen vertraust du einer Intel CPU jetzt noch?

Die Geschichte zu diesem Fehler ist in der Tat auch mehr als abenteuerlich! Das Segfault Problem ist in meinen Augen aber trotzdem schlimmer, denn;
- anscheinend ist der HT Bug mittlerweile durch ein Microcode Update gefixt (https://www.heise.de/newsticker/mel...ntel-Prozessoren-macht-die-Runde-3755660.html)
- gab es ohne HT keine Probleme, während segfaults ohne SMT auf Ryzen dennoch auftreten (wenn auch seltener)
- war der HT bug schwer zu reproduzieren, während Segfaults afaik auf allen Ryzens auftreten und ein simpler Testcase schon lange existiert (ich warte noch drauf, dass jemand mit einer Woche 25+ CPU aufkreuzt, der ohne RMA was funktionierendes erhalten hat)

Anscheinend hat Intel also im brain department, was es benötigt, um das Problem aus dem Weg zu räumen, während AMD Lotterie spielt und Austauschchips einzeln testet.

 

[Txxxxs]

Anscheinend hat Intel also im brain department, was es benötigt, um das Problem aus dem Weg zu räumen, während AMD Lotterie spielt und Austauschchips einzeln testet.

Ich habe den Eindruck, es handelt sich bei dem Problem um einen Produktionsfehler, der in den neueren Chargen nicht mehr auftritt bzw. behoben wurde. Es ist auffällig, dass Nutzer der älteren CPUs diesen Fehler reproduzieren können, bei den Austausch-CPUs, die alle aus neueren Chargen stammen, bisher nicht. Im AMD-Forum meine ich auch gelesen zu haben, dass diese neueren CPUs zudem mit einer geringeren Spannung und Temperatur arbeiten würden. Leider verliert man dort schnell den Überblick, weil die Leute, nachdem sie ihre Austausch-CPU erhalten und entsprechend nochmal getestet haben, direkt mit irgendwelchem Übertakten anfangen ...

Gibt es hier niemanden, der in den letzten Tagen oder Wochen bei gängigen deutschen Händlern (z. B. Mindfactory) einen Ryzen bestellt hat und zufällig weiß, in welcher Kalenderwoche er produziert wurde?

 

[kratpi]

Gibt es hier niemanden, der in den letzten Tagen oder Wochen bei gängigen deutschen Händlern (z. B. Mindfactory) einen Ryzen bestellt hat und zufällig weiß, in welcher Kalenderwoche er produziert wurde?

Sieht man das ohne die Verpackung aufmachen zu müssen?
Morgen erhalte ich einen 7 1800x von Mindfactory aber nicht für mich daher kann und will ich nicht öffnen.

 

[Anabolos]

Ja, auf der Seite siehst du die CPU. Mein 1600X, den ich heute in Österreich gekauft habe ist vom Batch UA1719SUT.

 

[Dj_Meff]

Ich bekomme meinen neuen heute geliefert von mindfactory meld mich nochmal wenn er da ist ( r7 1700)

 

[DEFCON2]

Meinen Ryzen habe ich Mitte Juni von Mindfactory gekauft. Er hat die Kennung UA 1714PGT und wird wegen der Segfaults von mir heut Mittag zur Post gebracht.

 

[Dj_Meff]

So meiner is da ua1719pgt

 

[Andi07]

Hallo zusammen!

Das bedeutet doch, dass dieser Prozessor 2017 und in der Kalenderwoche 14 hergestellt wurde.? Also Anfang April 2017.?

Na allen Betroffenen wünsche ich jedenfalls eine zufriedenstellende Lösung beim Ryzen-Problem!

Gruß Andi

 

[DEFCON2]

Soweit ich weiß bedeutet es genau das. Ob AMD das Bezeichnungsschema bestätigt hat, weiß ich nicht, aber es macht irgendwo Sinn .

@DJ_meff: Dann würde es sich evtl. lohnen, mal das GCC Compile-Skript drüber laufen zu lassen - vorausgesetzt, paralleles Kompilieren unter Linux gehört zu deinem (potentiellen) Workflow oder du willst aus Prinzip einen Prozessor, der i.O. ist. Du kannst ja noch bequem zurückgeben, falls nicht.

 

[kratpi]

Leider hat die Post geschlafen und der ryzen kommt erst morgen. Jedenfalls gemäß Sendungsverfolgung. Aber das hies es für heute auch schon. Ich werde nicht vergessen nachzusehen und zu berichten.

 

[Ph4ntom]

So habe mal nachgeschaut : UA: 1707PQT Also wohl einer der ersten Ryzen... Ich frage mich jetzt ob dringender Handlungsbedarf besteht, denn ich habe wohl einer sehr gute CPU erwischt bezüglich OC.

 

[DEFCON2]

Solang zu deinem Workflow kein massives paralleles Kompilieren unter Linux gehört besteht nach derzeitigem Stand der Dinge kein dringender Handlungsbedarf, denn die CPUs tun ihren Dienst davon abgesehen! Alles weitere wird man abwarten müssen (oder selbst testen).

PS: Du kannst das Problem mit dem genannten Shell Script testen

 

[Stuntmp02]

Man muss hier aber auch mal die Kirche im Dorf lassen. Der aktuelle Fehler ist interessant für User wie DEFCON, die mit ihren Systemen Code unter Linux kompilieren. Wenn ihr zu dieser Zielgruppe gehört, müsst ihr handeln, aber wenn ihr betroffen seid, dann würden keine Fragen kommen wie "Wie kann ich das unter Linux testen?".

Für den gesamten Rest muss man sagen, dass der Fehler unter enormer Wahrscheinlichkeit nie auftreten wird - Im gesamten Leben nicht. Viele übertakten Ihre Ryzen Systeme und sorgen sich nun über die Stabilität wegen diesem Errata, das ist einfach nur hirnlos. Mit Übertakten bringt man ein vielfaches an Instabilität ins System, als mit diesem Bug, jeder der übertaktet, dem kann dieser Errata vollkommen egal sein.

Es gibt hunderte Bugs in jedem einzelnen Prozessor, hier könnt ihr mal bei der Kaby Lake Generation stöbern. Es sind 6 Seiten an Erratas, die vermutlich niemals unter normalen Bedingungen auftreten.

Also nochmal zum mitschreiben: Schlimm für alle, die kompilieren unter Linux, egal bei allen Windows Gamern. Sollte sich dieser Zustand in der Zukunft ändern - Games deshalb abstürzen oder sowas - habt ihr so oder so 3 Jahre Garantie, in dieser Zeit kann man immernoch einen Support Case eröffnen und eine neue CPU erhalten. Potentiell verbessert sich die Fertigung ohnehin ständig, d.h. je neuer ein CPU produziert ist, desto größer ist das Potential für gutes OC. - Demnach ist eine spätere RMA auch kein Nachteil.

Es gibt aktuell für den typischen Windows Gamer keine Not, hier irgendwas zu tun. Das ist einfach nur viel Aufwand für nichts. Der Hype, der hier durch Golem provoziert wird, ist einfach vollkommen ungerechtfertigt, deshalb finde ich es auch gut, dass CB diesen Blödsinn nicht auch noch unterstützt mit einer panikmachenden Berichterstattung.

 

[LordLaden]

Nur als Hinweis für dich Errata = Plural.
Btt:
Zudem kann es sein, dass der Fehler auch bei anderen Kalkulationen auftritt. Nur weil bislang einzig Compiler den Fehler feststellen konnte heißt es nicht, dass er bei anderen Anwendungen nicht auch auftritt und zu unerwünschten Ergebnissen führt.

 

[Ph4ntom]

Solang zu deinem Workflow kein massives paralleles Kompilieren unter Linux gehört besteht nach derzeitigem Stand der Dinge kein dringender Handlungsbedarf, denn die CPUs tun ihren Dienst davon abgesehen! Alles weitere wird man abwarten müssen (oder selbst testen).

PS: Du kannst das Problem mit dem genannten Shell Script testen

Hauptsächlich ein paar Spiele und Video -Musik Bearbeitung. Werde trotzdem mal mit dem Script testen später

 

[kratpi]

UA1721SUT 1800x
Mindfactory heute angekommen

 

[DEFCON2]

@Stunrise:

Prinzipiell sehe ich das genau so wie du, je mehr ich mich in die Sache einlese, desto erstaunter bin ich, dass das überhaupt alles so gut funktioniert.

Allerdings muss man auch sagen, dass die Kommunikation von AMD zu wünschen übrig lässt. Es werden zwar anscheinend gute CPUs als RMA verteilt, aber solange nicht ein paar mehr Details verkündet werden, kann ich jeden verstehen, der bei kritischeren Anwendungen als Gaming und Office der CPU nicht mehr vertraut. Bei Intel wird das ja anscheinend regelmäßiger dokumentiert, das wäre doch mal ein Anfang. Insgesamt lässt die Lage schon die Interpretation zu, dass hier das Ausmaß ein wenig unter den Tisch gekehrt werden soll.

 

[Stuntmp02]

Es geht hier nicht darum, etwas unter den Tisch zu kehren, aber man muss es halt auch so sehen: JEDER EINZELNE CPU hat hunderte dieser Fehler und man kann als Hersteller nicht wegen jedem Blödsinn hier eine Rückrufaktion starten. Für jedem betroffenen steht eine RMA zur Verfügung, aber hier die Gamer wuschig zu machen, welche ihre Prozessoren auch noch übertaktet laufen lassen, ist totaler Blödsinn. Hier geht es auch nicht um AMD vs Intel, die Errata gibt es bei beiden zuhauf und das Vorgehen von AMD, hier Prozessoren zu tauschen, ist doch einwandfrei, was soll AMD denn sonst noch machen? Diese Fehler sind bei Milliarden an Transistoren vollkommen unvermeidbar, das ist eine Eigenschaft von Prozessoren - egal von welchem Hersteller.

Kennst du die Fehler Liste bei HyperV und ESX Server? Die sind dutzende Seiten lang, wenn man das liest ist man der Meinung Snapshots führen zum sofortigem Tod. Na und, fast alle Unternehmen weltweit nutzen die Virtualisierung, da kann man nicht wegen jedem Pups das Produkt gleich umtauschen wollen.

Hier wird einfach ein riesen Fass wegen etwas vollkommen normalen aufgemacht. Wie gesagt, wenn kompilieren unter Linux zu den Aufgaben des PCs gehört, ist eine RMA sinnvoll. Aber auch nur dann!

 

[Simpson474]

Falls es sich bei den gcc Abstürzen nicht um das Problem aus dem BSD-Workaround handelt, so ist ein Umtausch momentan die einzig sinnvolle Aktion. Ja auch Intel CPUs haben sehr viele Fehler, es ist bei der schieren Komplexität einfach nicht mehr möglich, fehlerfreie CPUs zu entwickeln. Das musste ich bei meinem Intel i5-5675C auch feststellen, der Start von Ubuntu in einer virtuellen Maschine führte reproduzierbar zu einer MACHINE_CHECK_EXCEPTION im Host-System. Kurz vor der Verzweiflung habe ich ein neues UEFI mit Microcode-Update eingespielt und der Fehler ist nie wieder aufgetreten.

Bei AMD scheint es aktuell jedoch so, als wäre die Ursache kein Chip-Errata, ansonsten könnte man einen Workaround anbieten, entweder per AGESA Update oder falls es nicht anders geht, durch Workarounds in den Compilern, um bestimmte Anweisungen nicht zu verwenden. Die wahre Ursache ist daher wohl ein Fertigungsproblem beziehungsweise mangelnde Testtiefe. Die Hersteller verwenden aufwändige Tests, um defekte Chips zu finden und z.B. die spezifische Core-Spannung für einen Chip zu ermitteln. Gerade zu Beginn einer neuen Chipproduktion sind diese Testprogramme noch nicht ausgereift und eine größere Anzahl defekter Chips kann in den Handel gelangen. Wir hatten in der Arbeit schon Bauteile mit dem gleichen Fehlerbild, welches in mehr als 1% aller gelieferten Chips vorhanden war. Nach langer Analyse wurde das Testprogramm beim Halbleiterhersteller erweitert um die defekten Chips korrekt auszusortieren und seitdem ist kein einziger Chip mit diesem Fehler mehr ausgefallen. Sollte das auch der Fehler bei AMD sein, so wird das Problem früher oder später auch bei anderen Programmen auftreten, nicht nur beim gcc.

 

[Stuntmp02]

Da liegst du meines Erachtens daneben, weil dann würde das Problem nur bei einem kleinen Teil der CPUs vor KW25 existieren, de facto sind aber alle betroffen. Oder gibt es CPUs vor KW25, die das Problem nicht haben?

Ein Errata kann man oft nicht durch ein BIOS Fix beheben, siehe die Liste von Intel und die Lösung "No Fix"