News Fehler in systemd lässt Linux bei Boot auf Ryzen 3000 abstürzen

[Nero24]

Zur Markteinführung der neuen AMD Ryzen 3000 “Matisse” sind zahlreiche Reviews erschienen. Passend zum Themenschwerpunkt hat die Webseite Phoronix mit Linux als Betriebssystem getestet und stieß dabei auf unerwartete Probleme. Während Linux-Distributionen wie Ubuntu 18.04 LTS problemlos starteten, stürzten brandaktuelle Distributionen wie Ubuntu 19.04 oder Fedora Workstation 31 unmittelbar beim Systemstart ab.
(…)

» Artikel lesen

 

[Pegasushunter]

Habe eben bei Ubuntu ein Update für systemd bekommen, glaube verstanden zu haben (im Changelog), dass der Fehler beseitigt wurde. Können ja die Englischprofis mal drüberlesen.

Gruß Pegasus

 

[tomturbo]

Nützt ja nix wenn die bootcd bereits streikt.

systemd wie es leibt und lebt: ein reiner Krampf.
Unmöglich einzugreifen, wenns mal wo hakt. Das ist windowsniveau, traurig.

 

[mmoses]

Nützt ja nix wenn die bootcd bereits streikt.

systemd wie es leibt und lebt: ein reiner Krampf.
Unmöglich einzugreifen, wenns mal wo hakt. Das ist windowsniveau, traurig.

ich sach nur Flatpack/Snap auf dem Desktop Da könnt ich im weiten Strahl k0tz3n

 

[Nero24]

Hm, AMD-Prozessoren unterstützen RDRAND überhaupt erst seit Excavator (Carrizo/Bristol Ridge). Da hat man sich wohl ein Ei gelegt mit der Implementierung...?

 

[Stefan Payne]

Es gibt auch die Behauptung, dass Destiny 2 nicht auf Matisse läuft.
https://www.reddit.com/r/DestinyThe...3000/?utm_medium=android_app&utm_source=share

Ev. kann das ja jemand mit Destiny 2 testen?

Ich hab (leider) noch keine Matisse...


Hätt halt gern den 3800X + Navi. Aber die üblichen Problemchen...

 

[wormy]

Pöttering hat wie üblich gepfuscht!
https://www.heise.de/forum/heise-on...-zu-Fall/Re-CPU-Fehler/posting-34830626/show/
1. Anwendungsprogramme dürfen/sollten nicht direkt auf Hardware zugreifen
2. Er war zu blöd, die Spezifikationen zu lesen und zu verstehen
3. Sind immer die anderen schuld

 

[tomturbo]

Ein Wahnsinn dieses Systemd Ding.
Das gehört endlich aus der Welt oder von professionellen Entwicklern übernommen.

 

[Stefan Payne]

Ist Microsoft nicht dran?
*scnr*

 

[wormy]

Ist Microsoft nicht dran?
*scnr*

Tja, im Vergleich zu Pöttering haben die etwas mehr Ahnung von Programm-Design und -Entwicklung.

 

[pipin]

Tja, im Vergleich zu Pöttering haben die etwas mehr Ahnung von Programm-Design und -Entwicklung.

Nur ist das bei MS dann nicht oft das Können, sondern das Wollen.

 

[Berniyh]

Ehrlich gesagt kann ich das Drama nicht wirklich verstehen, so schlimm ist das nun auch wieder nicht.
Also es ist natürlich schon doof, dass das System nicht startet, aber da habe ich schon wesentlich schlimmere Fehler gesehen, sowohl auf HW- als auch SW-Seite.

Gegen die Aktion, welche ext4 vor einigen Monaten veranstaltet hat (genauer war es gar nicht ext4, sondern ein anderes Subsystem im Linux Kernel, die Auswirkungen wurden aber in ext4 deutlich) ist das Kindergarten.

 

[mmoses]

Ein Wahnsinn dieses Systemd Ding.
Das gehört endlich aus der Welt oder von professionellen Entwicklern übernommen.

Bitte UEFI gleich mitentsorgen!

 

[MagicEye04]

Ehrlich gesagt kann ich das Drama nicht wirklich verstehen, so schlimm ist das nun auch wieder nicht.
Also es ist natürlich schon doof, dass das System nicht startet, aber da habe ich schon wesentlich schlimmere Fehler gesehen, sowohl auf HW- als auch SW-Seite.

Doch, ein nicht startendes System ist schlimm.
Ich will nicht wissen, wie viele Leute diesen Linux-Bug dann wieder AMD in die Schuhe schieben.

 

[Berniyh]

Doch, ein nicht startendes System ist schlimm.
Ich will nicht wissen, wie viele Leute diesen Linux-Bug dann wieder AMD in die Schuhe schieben.

Geht so, da gibt es viel schlimmeres. Eine nicht startendes System ist ärgerlich, solange der Fehler schnell gefunden und behoben werden kann.
Der Fehler zum C6 State, welcher die Gen1 Ryzen betrifft ist in meinen Augen wesentlich übler, da bis heute nicht so 100%ig klar ist, wo das her kommt und es meines Wissens nach wie vor nicht gefixt ist.

Es ist natürlich um so ärgerlicher, wenn man den Fehler auch noch auf Live-CDs / Installations-CDs untergebracht hat, da diese normalerweise nicht allzu oft ausgetauscht werden.
Muss man hoffen, dass das in diesem Fall (schnell) passiert.

Abgesehen davon: unschuldig ist AMD an dieser Aktion leider nicht, denn es handelt sich durchaus um einen HW Bug.
Ob systemd damit dann auch so umgehen muss ist natürlich eine andere Frage, prinzipiell ist das was sie machen aber erstmal legitim, auf Grund des bekannten HW Bugs aber natürlich nicht sinnvoll.

Edit: ich sollte noch hinzufügen, dass ich es auch sehr schwach von AMD finde offenbar nur eine einzige Version einer Distribution getestet zu haben.
Schon klar, dass man nicht alle 1000 Distributionen testet, aber so die 5 gängisten wären schon gut.

 

[Nero24]

Abgesehen davon: unschuldig ist AMD an dieser Aktion leider nicht, denn es handelt sich durchaus um einen HW Bug.

Naja, das ist soooo klar nicht. Wenn ich das hier...
https://www.heise.de/forum/heise-on...-zu-Fall/Re-CPU-Fehler/posting-34830626/show/

Software must test the state of the CF flag prior to using the value returned in the destination register to determine if the value is valid. If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.

... richtig interpretiere, dann steht im Programmierleitfaden von AMD genau drin, wie der RDRAND-Befehle zu handhaben ist; nur hält sich systemd offenbar nicht daran.

 

[Berniyh]

Ja, aber:

If CF = 1, the value is valid. If CF = 0, the value is invalid.

Auf CF=0 wird bei systemd wohl überprüft.
Scheibar gibt AMD aber nicht CF=0, sondern CF=-1 aus und daher kommt es zum Fehler.

 

[Onkel_Dithmeyer]

Der Fehler zum C6 State, welcher die Gen1 Ryzen betrifft ist in meinen Augen wesentlich übler, da bis heute nicht so 100%ig klar ist, wo das her kommt und es meines Wissens nach wie vor nicht gefixt ist.

Gebe ich dir vollkommen Recht, der Fehler soll aber ab Produktionswoche 25 behoben sein.

 

[Muku-Muku]

Ja, aber:

If CF = 1, the value is valid. If CF = 0, the value is invalid.

Auf CF=0 wird bei systemd wohl überprüft.
Scheibar gibt AMD aber nicht CF=0, sondern CF=-1 aus und daher kommt es zum Fehler.

Wie kann ein Flag -1 sein?

 

[eratte]

Für golem ist der Schuldige eindeutig:

Linux-Abstürze: Fehlerhafter Zufallsbefehl auf neuen und alten AMD-CPUs (golem)

Der Grund ist eine fehlerhafte Implementierung des Zufallszahlengenerators der CPU, den Systemd aufruft. Systemd arbeitet aber völlig korrekt, das Problem liegt in der CPU

 

[tomturbo]

Es ist vollkommen egal was das letztendliche Detail ist was zum fehlerhaften Verhalten von systemd führt.
Fakt ist hier wird falsch, nicht abbrechbar, für sinnlose UUIDs, eine Endlosschleife von systemd produziert, ohne auf die dokumentierten Designrichtlinien von AMD einzugehen.
Was zum Stillstand bei boot führt.
Nochmal: Das fehlerhaft Verhalten des Stillstands wird eindeutig von systemd erzeugt.
Bei anderen Initsystemen kann man wenigstens mit ctrl-c arbeiten um nicht weiterlaufende Skripts aufzuhalten oder in den single user mode zu gehen.
Aber nix da bei systemd

 

[eratte]

Ja aber solche Aussagen wie bei golem machen die Runde.

 

[Berniyh]

Bei anderen Initsystemen kann man wenigstens mit ctrl-c arbeiten um nicht weiterlaufende Skripts aufzuhalten oder in den single user mode zu gehen.
Aber nix da bei systemd

Du kannst doch auch bei systemd in den single user mode / recovery mode gehen?

Was mich zudem noch die ganze Zeit verfolgt: man kann die HW random generator in der CPU ja per Kernel Option ignorieren.
Kann man das nicht auch per cmdline an den Kernel weitergeben, so dass der nicht genutzt wird und das System bootet?

 

[Denniss]

Es ist sowieso fraglich warum da direkt auf die CPU zugegriffen wird anstatt den vorgesehenen Weg über die Kernelfunktion zu gehen.
Workarounds für CPU-Bugs werden im Kernel eingepflegt also warum setzen sich die Entwickler von systemd solchen möglichen Gefahren aus ?

 

[tomturbo]

Du kannst doch auch bei systemd in den single user mode / recovery mode gehen?

Man könnte, aber da systemd auch im single user mode startet, bootet das wohl auch nicht.

Was mich zudem noch die ganze Zeit verfolgt: man kann die HW random generator in der CPU ja per Kernel Option ignorieren.
Kann man das nicht auch per cmdline an den Kernel weitergeben, so dass der nicht genutzt wird und das System bootet?

Es wird nicht die Kernelschnittstelle verwendet sondern direkt der CPU-Befehl. Da hilft der Parameter nicht.