Ryzen 3000: Bekannter Fehler bringt viele Linux-Distributionen zu Fall

Bei der Nutzung des Zufallszahlengenerators von Ryzen-Prozessoren gibt es mit Linux ein Problem, durch das viele aktuelle Linux-Distributionen auf dem am Sonntag vorgestellten AMD Ryzen 3000 nicht booten. 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.

Das Problem tritt unter anderem mit Ubuntu 19.04, Fedora 30 oder dem aktuellen Manjaro auf – sowohl bei installierten Fassungen als auch als beim Start von Installationsmedien. Das ebenfalls am Wochenende erschienene Debian 10 sowie die älteren Distributionen Ubuntu 18.04 und Fedora 29 starten hingegen.

Nutzung des Zufallszahlengenerators triggert den Fehler

Das eigentliche Problem ist schon seit dem Herbst 2014 bekannt: Bei manchen Systemen mit älteren AMD-Prozessoren gerieten schon die Systemd 240, 241 und die aktuelle Version 242 aus dem Tritt, wenn das System aus dem Bereitschaftsmodus (Suspend) aufwacht. Mit vorherigen Systemd-Versionen lief hingegen alles normal, weil erst eine bei 240 hinzugefügten Codestelle das Problem triggert, die Zufallszahlen per RDRAND-Instruktion direkt vom Prozessor holt. Die Entwickler haben diese Codestelle daraufhin vor einigen Wochen im Entwicklerzweig nochmal angepasst, damit Systemd das Fehlverhalten bei betroffenen CPUs abfangen kann; bei dieser Änderung haben sie betont, dass das eigentlich ein Fehler ist, den Kernel oder BIOSen handhaben müssten, weil er sonst auch andere Programme betreffen kann.

Bei AMD Ryzen 3000 tritt das Problem nicht erst beim Aufwachen aus dem Bereitschaftsmodus auf, sondern schon beim Systemstart: Das zeigte sich im c't-Testlabor, denn Ubuntu 19.04, Fedora 30 oder Manjaro booten auf mehreren Mainboards nicht mit einem Ryzen 3000. Mit einem Ryzen 2000 liefen die Boards aber problemlos. Wir haben daraufhin mit einem solchen ein Fedora 30 installiert und die dort eingesetzte Systemd-Version mit der Korrektur für das Problem versorgt. Anschließend konnten wir den Ryzen 3000 wieder einsetzen und siehe da: Die Linux-Distribution startete ganz normal.

Distributionen am Zug

Ubuntu 18.04 und Fedora 29 nutzen ein älteres Systemd, daher zeigt sich das Problem dort nicht. Debian 10 wäre eigentlich auch von der Macke betroffen gewesen, denn es nutzt Systemd 241; die Distribution läuft aber, da die Debian-Entwickler die Korrektur für das Problem kurz vor dem Release noch in ihr Systemd-Paket integriert haben.

Diesen Weg müssten jetzt auch die Macher von Fedora 30, Ubuntu 19.04 & Co. gehen. Damit sich diese Distributionen aber auch installieren lassen, müssten die Entwickler aber auch neue Installationsmedien bereitstellen. Diesen Aufwand scheuen die Macher der meisten konservativ gewarteten Distributionen. Vermutlich werden diese das Problem daher erst mit den nächsten, im Herbst erwarteten Versionen wie Fedora 31 und Ubuntu 19.10 angehen, die den Bugfix dann mit Systemd 243 oder neuer frei Haus bekommen dürften. Abzuwarten bleibt auch, ob auch die Linux-Kernel- oder BIOS-Entwickler eine Korrektur oder einen Workaround einbauen werden, um das Problem früher und für alle Programme abzufangen.

[Update 2019-07-10] Typo bei Jahreszahl und Prozessorbezeichnung korrigiert: Das Problem ist nicht erst seit 2018, sondern seit 2014 bekannt; es tritt zudem nicht bei früheren Ryzen-CPUs auf, sondern bei noch älteren AMD-Prozessoren. [/Update] (thl)