Diverse Linux-Distributionen lassen sich mit Ryzen-3000-CPUs nicht booten (Update)

[HWL News Bot]

Wie jetzt bekannt wurde, scheint der Zufallszahlengenerator der neuen Ryzen-Prozessoren Schwierigkeiten mit den diversen Linux-Distributionen zu haben. Besagte Probleme sorgen dafür, dass die dritte Generation unter Linux nicht booten will. Somit ist eine Ryzen-CPU der dritten Generation aktuell nicht kompatibel mit Linux, zum Beispiel mit Ubuntu in der Version 19.04. Aber auch Distributionen wie Fedora 30 oder das aktuelle Manjaro sind betroffen. Mit Ubuntu 18.04, Fedora 29 oder Debian 10 gibt es hingegen keinerlei Probleme. Die Systeme booten. Die Ursache für die Verweigerung des Startvorgangs ist bereits seit Herbst 2018 bekannt. Wie sich dem

 

[AliManali]

Bei Ubuntu habe/hatte ich immer wieder mal Probleme, dass es beim Start hängen bleibt (auf vSphere). Seither nehm ich auch nur noch LTS. Letzhin wollte ich bei einem 18.04.1 LTS die Aktualisierungen machen, danach ist es nicht mehr gestartet, bzw. beim booten hängen geblieben. Das Backup einspielen hat mich dann wieder paar Stunden gekostet. Nutze daher Ubuntu nur noch ungern. Mit Debian habe ich bislang weniger schlechte Erfahrungen gemacht.

 

[Gelöschtes Mitglied 288544]

Testet AMD nicht die Kompatibilität mit verschiedenen Betriebssystemen vorher? Wenn Inkompatibilitäten aufgefallen wären, hätte man den Leuten bei Red Hat (den systemd-Entwicklern) ja rechtzeitig (vor dem Release) Bescheid geben können. Die wollen mir ja nicht erzählen, das hardwarenahe Entwicklung bzw. Hardware-Entwicklung auf WIndows läuft.

Gibt es Probleme mit anderen init-daemons wie runit? systemd ist ja sowieso umstritten, aus Gründen der Sicherheit, Stabilität, Performance, Bugs und Nutzerfreundlichkeit (z.B Art der Abspeicherung der Logs) (wobei letzterer Punkt mich nicht betrifft, da ich als Nicht-Systemadministrator nichts daran konfiguriere).

Rolling Release hat schon seinen Vorteile - Updates sind viel einfacher/schneller durchzuführen und erscheinen häufiger - theorestisch also auch von der Sicherheit her besser.

 

[Mr.Mito]

@Cookie:

Das Problem und der Fehler liegt hier wohl kaum bei AMD und der Bug ist schon länger bekannt. Wenn das einer verpennt hat, dann andere Leute. Da wurden wohl die Prioritäten falsch gesetzt, weil das Problem bisher "nur" beim Standby auftrat.
Was RR mit Sicherheitsgewinn zu tun haben soll, ist mir auch schleierhaft. Neue Features sofort ausrollen erhöht die Sicherheit kein Stück und Sicherheitsupdates haben mit RR nichts zu tun.
Die kommen da auch nicht schneller, als bei einer gut gepflegten "normalen" Distri.

 

[Skizzi]

Der Fehler hier liegt sehr wohl bei AMD. Die können ja nicht einfach ne CPU verkaufen, die kaputte Kernelinstruktionen hat. Mal davon abgesehen, dass RDRAND auch echt wichtig für viele andere Kryptosachen ist. Wir können eigentlich sogar froh sein, dass es den Bug gibt.

 

[Mr.Mito]

Wie kommst du darauf, dass die CPU hier den Fehler provoziert und nicht die Software? Seit wann ist AMD für systemd Fehler verantwortlich?
Für mich las sich das in der News und den Bugtrackern genau anders herum, zumal ältere systemd Versionen keine Probleme haben.

GithubDowngraded packages systemd, lib32-systemd and systemd-sysvcompat to version 239.6-1 and it started working like a charm.

Bereits 2014 wurden die Probleme mit AMD CPUs gemeldet, nur halt damals lediglich beim aufwachen aus dem standby.

Hast du da andere Infos zu, also das AMD das verkackt hat? Wenn ja, wären Links dazu sehr hilfreich.

EDIT:

Mein Fehler, Fehler liegt tatsächlich bei AMD. Hatte ich dann komplett missverstanden.

#929215 - unblock: systemd/241-5 - Debian Bug report logs

 

[Tech Enthusiast]

Der Fehler hier liegt sehr wohl bei AMD. Die können ja nicht einfach ne CPU verkaufen, die kaputte Kernelinstruktionen hat.

Wieso ist es AMDs Aufgabe jede mögliche open Source Sache zu checken und entsprechend ihr Zeug anzupassen?
Das ist ne echte Firma, mit echtem Kapital und echtem Zeitplan und Druck.

Die können doch nicht auf Linux eingehen, wo jeden Tag irgendein neues Script Kiddie ne neue Distribution verbricht.
Linux hat sich gefälligst an die Hardware-Hersteller anzupassen, so wie jede andere Software auch. Ein kritischer Fehler wird es wohl kaum sein, da Windows ja stressfrei startet.
Und es ist auch weiß Gott nicht das erste Mal, dass Linux mit der aktuellsten Hardware nicht ordentlich funktioniert. Erinnere mich da an einen Arbeitslaptop meiner Frau, die Linux nutzen musste. Es musste neue Hardware sein, aufgrund der Leistungsanforderungen, aber selbst nach Tagen des neu installierens ging nix.
Alle möglichen Distros und Kernel Variationen wurden probiert, jeweils mit mind. 2 verschiedenen Treiber für GPUs.

Aktuelle Hardware und Linux sind keine gute Kombination.

 

[Skizzi]

Wenn die Instruktion kaputt ist, ist das n Problem von AMD, fertig. Was gibt's da zu diskutieren?

 

[Gamerkind]

Aktuelle Hardware und Linux sind keine gute Kombination.

Das ist eindeutig als total falsch zu werten!

Gerade für Linux gibt es lange bevor bei AMD Hardware auf den Markt kommt schon die Kernelpatches und Treiber.
Eben weil Linux im Servermarkt viel wichtiger als Windows ist.

 

[Spawn182]

Für einige hier scheint AMD echt schon ähnlichen Kultstatus zu haben wie Apple für entsprechende Jünger. Es kann nicht sein das AMD auch nur an irgendeiner Stelle mal nen Fehler macht oder gar flunkert, die sind immer korrekt und wollen auch nichts dabei verdienen

Insgesamt ist das doch kein Beinbruch, fast alle (vermutlich alle) CPUs haben den einen oder anderen Fehler, das wird nun halt per BIOS (oder alternativen Stellen) gefixt. Ist eigentlich keine Rede wert. Schade ist doch eigentlich nur, dass es im Vorfeld niemand für wichtig gefunden hat und es entsprechend schon bei Release gefixt wurde bzw. die Info an Entwickler raus geschickt hätte werden können.

 

[Gamerkind]

Der Fehler liegt bei BEIDEN Seiten!

Ja, der Ryzen gibt etwas aus, was nicht korrekt ist, also ein Fehler.

Aber die Software sollte nicht abstürzen, für den Absturz kann AMD nichts, das ist ganz klar ein Softwarefehler!

 

[Spawn182]

Aber die Software sollte nicht abstürzen, für den Absturz kann AMD nichts, das ist ganz klar ein Softwarefehler!

Das stimmt so nicht ganz, Systemd prüft ja das Ergebnis von RDRAND indem es eben auch das Carry Flag von der CPU abruft, welches aber im Falle von AMD 1 ist und behauptet RDRAND hätte einen zulässigen Wert. Hier liegt eindeutig ein Fehler seitens AMD vor und dieser kann in Software nur umschifft, aber nicht gefixt werden. Würde AMD CF auf 0 setzen wäre alles in Butter.

Sprich Systemd hat schon etwas geprüft, nur hat die Prüfung eben auch einen falschen Wert geliefert. Seitdem der Fehler bekannt ist, wurde das ja auch schon gefixt, ist halt nur nicht in allen Distros auf aktuellem Stand.

 

[GuruSMI]

Gerade für Linux gibt es lange bevor bei AMD Hardware auf den Markt kommt schon die Kernelpatches und Treiber.
Eben weil Linux im Servermarkt viel wichtiger als Windows ist.

Seit wann ist der Ryzen 3000 im Serverbereich positioniert? Hab ich was verpasst? MWn ist der Ryzen und AM4 noch immer eine Desktop Plattform. Davon ab haben beide Schuld. Der eine hat den Befehl nicht richtig implementiert. Der andere hat vergessen, eine Fehlerbehandlung zu implementieren. Allerdings sind das grundsätzlich zwei verschiedene Paar Stiefel. Mit dem Fehler des einen ist der Fehler des anderen aufgedeckt worden.

 

[Gamerkind]

Es geht um die Treiber (CPU und GPU) und da werden für Matisse und Rome teilweise die selben Kernelpatches verwendet.

 

[Gelöschtes Mitglied 288544]

Ich kenne mich mit Assembler nicht wirklich gut aus, aber: RDRAND scheint wohl eine Instruktion in dieser Sprache für x86/AMD64 zu sein? Und wenn AMD diese Instruktion falsch implementiert hat, dann ist das deren Schuld. Die Programmierer der x86-Versionen von systemd werden ja wohl voraussetzen dürfen, dass der Befehlssatz auf dem Prozessor korrekt funktioniert und implementiert wurde.

Ich denke, zu sagen, der Fehler läge auf beiden Seiten, wäre so, wie zu sagen, dass beide Seiten Schuld seien, wenn ein C-Programm nicht funktioniert, weil der Compiler z.B. getchar() nicht übersetzen kann.

 

[Gamerkind]

Ich denke, zu sagen, der Fehler läge auf beiden Seiten, wäre so, wie zu sagen, dass beide Seiten Schuld seien, wenn ein C-Programm nicht funktioniert, weil der Compiler z.B. getchar() nicht übersetzen kann.

Du kennst es natürlich sehen wie du willst, aber wenn die Software einfach abstürzt, ist das als Softwarefehler zu sehen!

 

[Oberst]

Wäre es ein reines Hardware Problem, dann wäre folgendes nicht möglich:

Mit Ubuntu 18.04, Fedora 29 oder Debian 10 gibt es hingegen keinerlei Probleme.

Insofern liegt hier durchaus auf beiden Seiten ein Problem vor.

 

[Gelöschtes Mitglied 288544]

Wäre es ein reines Hardware Problem, dann wäre folgendes nicht möglich:

Insofern liegt hier durchaus auf beiden Seiten ein Problem vor.

Vielleicht verwenden gewisse systemd-Versionen einfach kein RDRand?

 

[Gamerkind]

Darum geht es doch nicht, auch wenn das genutzt wird, darf die software nicht einfach das System in den Abgrund reißen!

 

[Elmario]

Dagegen kann die Software bei einem Hardwareproblem je nach Fehler gar Nichts tun. Und eine fehlerhaft implentierte Instruction ist ein Hardwareproblem, auch wenn man es durch Workarounds umschiffen kann, was aber mitunter ordentlich Leistung kosten kann und nicht das Ziel sein kann.
Wenn eine CPU fehlerhafte Ergebnisse liefert, ist es der Normalfall, dass dei Software crasht, auch wenn man seit einiger Zeit Versuche unternimmt das zu umschiffen, bzw. zu verstecken.

 

[Gamerkind]

Auch wenn das noch einige immer wieder behaupten, wahr wird es halt dadurch nicht!

 

[Elmario]

Deiner Theorie nach (nämlich dass die korrekte Ausführung von CPU-Instructions in der Hand der Software liegt) könnte ein PC doch niemals instabil werden, sofern die Software nur weit genug entwickelt ist - ganz egal wie alt und defekt der PC vielleicht auch ist. Das einzige Layer, das noch dazwischen liegt, ist die Übersetzung auf MicroOPs, und auch diese ist Sache des Hardwareherstellers.