News Ryzen 3000: BIOS-Update gegen Probleme mit Linux und Destiny 2

[yummycandy]

@yummycandy
Willkommen in der Softwareentwicklung, kein Programmierer schreibt Software so, dass alle etwaigen Bugs / Errata aller x86, ARM, MIPS, Power, Sparc, Alpha, Ra-Risc, IA64, m68k, MicroBlaze, Xtensa, AVR32, RiscV CPUs beachtet werden würden.

Wäre dem so, wäre das typische "hello World" mal fix einige tausend Zeilen Code länger -.-

Nein, natürlich nicht alle. Aber Code wird auch getestet und je nach Feedback werden auch Workarounds gebaut. Ist ja wohl nichts neues. Schon gar bei Hardware, weil man sowieso erstmal nichts dran ändern kann. Wie gesagt, der Bug ist nicht neu.

 

[ghecko]

ja, son scheiß, genau. nämlich scheisse programmiert, muss das programm halt abchecken, wenn zwei zufahlszahlen gleich sind. und dann halt +1 rechnen oder was auch immer.

Ich denke nicht dass Poettering ein Exklusivsample unter NDA bekommen hat und ein halbes Jahr Zeit hatte in der Architektur nach Fehlern zu stochern.
Nochmals, der Fehler liegt nicht in systemd, das tut genau das was es soll. Das hat nichts mit scheiße programmiert zu tun. Rein gar nichts.

 

[Piktogramm]

ja, son scheiß, genau. nämlich scheisse programmiert, muss das programm halt abchecken, wenn zwei zufahlszahlen gleich sind. und dann halt +1 rechnen oder was auch immer.

Der Test ob sich Zufalszahlen doppeln wird gemacht und ist der Grund wieso Systemd in Endlosschleifen feststeckt.

+1 ist keine Lösung für das Problem. SystemD arbeitet massiv nebenläufig (multiprozessing). Wenn da mehrere Prozesse jeweils die gleiche Zufallszahl bekommen und je +1 vergeben hat man genauso wieder Kollisionen. Um dem zu begegen müsste man auf Rechnern die locker mal 100+ Threads laufen haben die Vergabe von IDs zu synchronisieren. Das ist bei der Entwicklung her aufwendig, frisst CPU-Zeit ohne Ende und von den Problemen des Rechtemanagements fangen wir nicht an. schauder

 

[yummycandy]

Bei Zen/Zen+ funktioniert es seltsamerweise. Da ist man eben davon ausgegangen, dass es bei Zen2 genau so ist.

Nein, hats nicht immer.

Den eigentliche Fehler zeigen auch schon frühere Prozessoren gelegentlich, bei der neuen CPU-Familie tritt er aber ständig auf. Der System- und Service-Manager Systemd gerät dadurch so stark aus dem Tritt, dass der Systemstart mit dem neuen Ryzen scheitert.
https://www.heise.de/newsticker/mel...ele-Linux-Distributionen-zu-Fall-4465220.html

 

[ghecko]

Nein, hats nicht immer.

Laut Golem schon:

Besonders kurios an dem Fehler ist, dass der Befehl auf den älteren Ryzen-Chips wie gewünscht funktioniert und damit auch aktuelle Linux-Distribution mit dem aktuellen Systemd problemlos booten.

https://www.golem.de/news/linux-abs...-und-alten-amd-cpus-1907-142433.html#comments

Mit "gelegentlich" meint Heise nicht Zen/Zen+ sondern Carrizo, Puma und Jaguar:

Laut diesem Bugreport, der bereits 2014 erstellt wurde, gab es Probleme mit dem rdrand-Befehl bereits bei einem Prozessor aus der Jaguar-Reihe von AMD. Auch die initiale Fehlermeldung im Bugtracker von Systemd verweist auf ältere APUs von AMDs Carrizo-Reihe mit Puma-Architektur. Bei den älteren CPUs betrifft der durch Systemd ausgelöste Fehler den Meldungen zufolge jedoch nicht direkt den Boot, sondern zunächst wohl nur den Ruhezustand (Suspend).

 

[Sukrim]

Hier übrigens der kernelseitige Bugreport zu AMD CPUs mit diesem Fehler von 2014: https://bugzilla.kernel.org/show_bug.cgi?id=85911

 

[yummycandy]

Laut Golem schon:

https://www.golem.de/news/linux-abs...-und-alten-amd-cpus-1907-142433.html#comments

Mit "gelegentlich" meint Heise nicht Zen/Zen+ sondern Carrizo, Puma und Jaguar:

Hast du dir mal deinen verlinkten Artikel durchgelesen? Es läuft auch auf alten CPUs nicht korrekt.

 

[Kamui18]

Stimmt, bei Intel kommt das teils erst Jahre später ans Licht, das ist viel besser.
AMD hingegen überlässt nichts dem Zufall.
Pun intended.

Laut dem Artikel ist der Fehler schon seit 2014 bekannt und tritt auch bei älteren AMD CPU's auf

https://www.heise.de/newsticker/mel...ele-Linux-Distributionen-zu-Fall-4465220.html

 

[owned139]

Hast du dir mal deinen verlinkten Artikel durchgelesen? Es läuft auch auf alten CPUs nicht korrekt.

Auf Intel schon. Die haben den Bug wohl adaptiert? Merkste hoffentlich selbst.
Auch AMD macht Fehler.

 

[ghecko]

Hast du dir mal deinen verlinkten Artikel durchgelesen? Es läuft auch auf alten CPUs nicht korrekt.

Na ja, ich weiß nicht wie oft ich diese Stelle noch aus dem Golem Artikel zitieren soll:

Besonders kurios an dem Fehler ist, dass der Befehl auf den älteren Ryzen-Chips wie gewünscht funktioniert und damit auch aktuelle Linux-Distribution mit dem aktuellen Systemd problemlos booten.

Zen/Zen+ ist nicht betroffen, hier funktioniert rdrand zuverlässig. Man ist davon ausgegangen, es ist gefixt. Also hat man es implementiert.

Ich hab den Artikel gelesen, übrigens schon vor ein paar Tagen. Da hab ich ihn auch in den Masterthread gepostet.
https://www.computerbase.de/forum/t...t-die-kroenung.1880423/page-188#post-22856380

 

[yummycandy]

Auf Intel schon. Die haben den Bug wohl adaptiert? Merkste hoffentlich selbst.
Auch AMD macht Fehler.

Das hab ich doch oben geschrieben. Es ging in dem Fall nur um AMD CPUs. Ich wiederhole es nochmal, ja, AMD hätte das schon lange patchen können.

 

[Croftout90]

Bitte MSI, behebt auch gleich den Fehler mit den XMP-Profilen...

 

[yummycandy]

Na ja, ich weiß nicht wie oft ich diese Stelle noch aus dem Golem Artikel zitieren soll:

Diese hier?

Ein älterer Kernel-Bug weist darauf hin, dass das Problem auch in älteren AMD-Prozessoren auftauchen kann. Laut diesem Bugreport, der bereits 2014 erstellt wurde, gab es Probleme mit dem rdrand-Befehl bereits bei einem Prozessor aus der Jaguar-Reihe von AMD. Auch die initiale Fehlermeldung im Bugtracker von Systemd verweist auf ältere APUs von AMDs Carrizo-Reihe mit Puma-Architektur. Bei den älteren CPUs betrifft der durch Systemd ausgelöste Fehler den Meldungen zufolge jedoch nicht direkt den Boot, sondern zunächst wohl nur den Ruhezustand (Suspend).

Gleicher Bug, andere AMD CPU.

 

[ghecko]

https://www.golem.de/news/linux-abs...-und-alten-amd-cpus-1907-142433.html#comments

Letzter Absatz, diesmal vollständig:

Besonders kurios an dem Fehler ist, dass der Befehl auf den älteren Ryzen-Chips wie gewünscht funktioniert und damit auch aktuelle Linux-Distribution mit dem aktuellen Systemd problemlos booten. Sowohl auf den Vorgänger-Chips als auch auf den Nachfolgern treten jedoch die beschriebenen Probleme auf. Ein korrekter Fix wäre vermutlich über den CPU-Microcode möglich, dieser müsste aber direkt von AMD kommen.

Zen/Zen+ -> Nicht betroffen
Carrizo, Puma, Jaguar -> Bei suspend betroffen.

 

[yummycandy]

Zen/Zen+ -> Nicht betroffen
Carrizo, Puma, Jaguar -> Bei suspend betroffen.

Ich hab nicht behauptet, daß die Bootprobleme auch beim älteren Ryzen auftreten, sondern das der Fehler schon länger existiert. Gut möglich, daß eine Änderung im Design das jetzt provoziert, keine Ahnung.

https://www.computerbase.de/forum/t...mit-linux-und-destiny-2.1881517/post-22870451

 

[Amaoto]

Wie viele nutzen Linux? 3,5%!

So zu rechnen ergibt wenig Sinn. ComputerBase läuft z.B. mit Linux, d.h. jeder, der das hier liest, nutzt indirekt Linux. Würde man in den Server eine solche CPU einbauen, würde das System evtl. nicht booten und CB wäre offline.

 

[ghecko]

sondern das der Fehler schon länger existiert.

Nein, du sagst oben, Zen/Zen+ sei ebenfalls sporadisch betroffen.

Bei Zen/Zen+ funktioniert es seltsamerweise. Da ist man eben davon ausgegangen, dass es bei Zen2 genau so ist.

Nein, hats nicht immer.

Nachzulesen in #44

 

[yummycandy]

So zu rechnen ergibt wenig Sinn. ComputerBase läuft z.B. mit Linux, d.h. jeder, der das hier liest, nutzt indirekt Linux. Würde man in den Server eine solche CPU einbauen, würde das System evtl. nicht booten und CB wäre offline.

Gefühlt 99% aller Websites laufen auf Linux. Wird real natürlich etwas weniger sein.

Ergänzung (12. Juli 2019)

Nein, du sagst oben, Zen/Zen+ sei ebenfalls sporadisch betroffen.

Ich will da jetzt wirklich keinen Kindergarten draus machen. Ich hab nur einmal geschrieben: "Das rrand auf AMD Systemen nicht zuverlässig läuft, ist nicht erst seit Ryzen bekannt. " Damit waren logischerweise ältere CPUs vor Ryzen gemeint und nicht Zen+, bzw. Zen. Aber das ist mir auch etwas zu kleinkariert und ändert nichts an meinem ersten Posting hier.

 

[Silveran]

Fällt sowas nicht schon viel früher auf? Bei AMD sind die releases leider nicht so gut, Intel hat wenigstens stabile UEFIs auch für alte Chipsätze, Nvidia releast ein gutes Referenzmodell und Custom Designs, während AMD beim release instabile UEFIs (Beim X370 release und jetzt mit den alten AM4 Boards), Treiberprobleme (Radeon VII), keine Customdesigns (Radeon VII, Navi) und jetzt auch diesen m. M. n. schwerwiegenden Fehler. Testen die die CPUs nicht umfangreich? Auch wenn es für die meisten Gamer nicht schlimm ist, aber auf vielen Servern läuft Linux und wenn auf den Epic Servern kein Linux läuft, ist das für AMD ein schwerer Image Schaden. Ich habe das Gefühle das AMD Gamer und andere Ryzen 3000 Nutzer als Betatester für Zen 2 nützt. Lieber die CPUs eine Woche Später releasen und dann ohne Fehler statt ein schlechtes Image bekommen.

Typisch AMD,.. Nichts auf die Reihe bekommen, immer wenn sie was neues aufm Markt bringen, entweder zu laut, zu viel Strom oder Bug... Das... Ohne Worte. Da bleib ich lieber bei Intel und nvidia.. 😁😁😁

 

[Hauro]

Würde man in den Server eine solche CPU einbauen, würde das System evtl. nicht booten und CB wäre offline.

Kein Server verwendet einen Desktop-Prozessor sondern bei AMD EPYC, Intel Xeon, IBM POWER9, usw. und hier werden die Tests entsprechend umfangreich sein. Außerdem läuft hier Unix und nicht Linux.