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

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.472
@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

Rear Admiral
Dabei seit
Juli 2008
Beiträge
5.982
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

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.960
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

Captain
Dabei seit
März 2005
Beiträge
3.472
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/meldung/Ryzen-3000-Bekannter-Fehler-bringt-viele-Linux-Distributionen-zu-Fall-4465220.html
 

ghecko

Rear Admiral
Dabei seit
Juli 2008
Beiträge
5.982
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-abstuerze-fehlerhafter-zufallsbefehl-auf-neuen-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).
 

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.472

Kamui18

Lt. Junior Grade
Dabei seit
Sep. 2005
Beiträge
364

ghecko

Rear Admiral
Dabei seit
Juli 2008
Beiträge
5.982
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/threads/amd-ryzen-3000-im-test-das-ist-die-kroenung.1880423/page-188#post-22856380
 

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.472

Croftout90

Lieutenant
Dabei seit
Juli 2017
Beiträge
953
Bitte MSI, behebt auch gleich den Fehler mit den XMP-Profilen...
 

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.472
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

Rear Admiral
Dabei seit
Juli 2008
Beiträge
5.982
https://www.golem.de/news/linux-abstuerze-fehlerhafter-zufallsbefehl-auf-neuen-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

Captain
Dabei seit
März 2005
Beiträge
3.472
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/threads/ryzen-3000-bios-update-gegen-probleme-mit-linux-und-destiny-2.1881517/post-22870451
 

ghecko

Rear Admiral
Dabei seit
Juli 2008
Beiträge
5.982
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.
Nachzulesen in #44
 

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.472
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 ()

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

Lt. Commander
Dabei seit
Okt. 2006
Beiträge
1.671
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.. 😁😁😁
 
Top