c’t wirkt: Absturz-Problem mit Kingston-SSD des optimalen PC

Beim Linux-Einsatz auf vielen unserer jüngsten PC-Bauvorschläge kann ein Problem der Kingston-SSD zu Abstürzen führen. Der Hersteller wusste davon offenbar schon monatelang, hat aber nichts unternommen. Wir konnten einige Nutzer innerhalb eines halben Monats mit einem automatisch genutzten Workaround versorgen. Durch ihn steigt allerdings die Leistungsaufnahme auch bei Systemen, die nicht betroffen sind. Da ist jetzt Kingston gefragt. Doch der Reihe nach.

SSD stolpert

In vielen Bauvorschlägen der Artikelserien zum optimalen PC 2020 und 2021 haben wir eine SSD vom Typ Kingston A2000 NVMe PCIe eingesetzt. Sie hatte bei den ausgiebigen Tests, die solchen Texten ­vorausgehen, nie Probleme gezeigt – weder unter Windows noch bei den vielen Versuchen für die beiden Artikel, in denen wir die Linux-Tauglichkeit der verschie­denen Bauvorschläge beleuchteten [1, 2].

Nach dem zweiten Text informierte uns kürzlich ein Leser über Stabilitäts­probleme mit der SSD: Die Installation einer Linux-Distribution klappte, aber nach ein paar Stunden stürzte das System hart ab. So hart, dass das BIOS die SSD nach Betätigen des Reset-Knopfs nicht ­erkannte; sie kam erst wieder in Gang, nachdem der PC für ein paar Sekunden ausgeschaltet war.

Der Leser fand im Web mehrere ­Berichte von A2000-Besitzern, die mit ­demselben Phänomen zu kämpfen hatten. Einigen zufolge tritt das Problem erst mit der neuesten, seit Frühjahr 2020 verteilten SSD-Firmware auf. Laut einem Forenbeitrag weiß Kingston seit mindestens Mitte September 2020 von dem Problem. Einzelne Nutzer betonen aber, dass die SSD bei ihnen vollkommen störungsfrei läuft; allem Anschein nach zicken nur manche SSDs der Serie oder nur in bestimmten Konfigurationen.

In einigen Berichten fand sich auch gleich ein Lösungsvorschlag: Man solle die Nutzung der NVMe-SSD-Stromspartechnik „Autonomous Power State Transition“ (APST) einschränken. Manche Quellen rieten dazu, diese komplett zu deaktivieren; anderen zufolge reicht es, nur den tiefsten der APST-Modi zu meiden. Letzteres gelingt bei der A2000 über folgenden Kernel-Parameter: nvme_core.default_ps_max_latency_us=2500

Der deutsche Kingston-Support bestätigte dem Leser, vom Problem zu wissen; er riet zum Deaktivieren von APST und stellte ein Firmware-Update in Aussicht.

Der Leser leitete diese Information am 25. Januar an uns weiter. Daraufhin hakten wir bei Kingston nach und begannen parallel, das Problem nachzustellen. Nach zwei Tagen bestätigte uns der Hersteller das Ganze mit einem sehr kurzen und vagen offiziellen Statement; am Rande ließ man durchblicken, dass es am tiefsten APST-Modus liegt.

Abfangen

Das rief den Autor dieses Textes auf den Plan, der wusste, dass auch ein paar NVMe-­­SSD-Serien anderer Hersteller ­solche Probleme zeigen. Bei diesen vermeidet der Kernel die Nutzung des tiefsten APST-Modus automatisch: Das erhöht zwar die Leerlauf-Leistungsaufnahme ­minimal, doch stabile und korrekte Funktion geht für die Linux-Entwickler vor.

Diese und andere Sonderbehandlungen aktiviert der Kernel über eine Datenstruktur, in der neben Vendor- und Device-­IDs auch die Art der Macke (der „Quirk“) der SSD-Serie hinterlegt ist. Diese Datenstruktur kann man im Quellcode leicht erweitern, damit der Kernel den tiefsten APST-Level auch bei der Kingston-SSD automatisch meidet. Das gelingt innerhalb einer Minute und ohne Programmier-­Know-how, denn viel mehr als Copy & Paste ist dazu nicht vonnöten.

Um das Problem generell aus der Welt zu schaffen, muss der Quirk-Eintrag aber in den offiziellen Kernel einziehen. Dieses Ziel war deutlich schwerer zu ­erreichen, denn dazu muss man den Linux-­Entwicklern die Anpassung schmackhaft machen – dabei sollte man vor der Einreichung der Änderung aber auch ­geprüft haben, ob sie zum gewünschten Resultat führt. Das konnten wir aber nicht, da es uns nicht gelang, das Problem mit unseren SSDs zu reproduzieren.

Der Autor versorgte die Änderung daher mit einer sehr ausführlichen Patch-­Beschreibung, bevor er das Ganze per Mail an die für NVMe-Code zuständigen ­Entwickler schickte. Nach wenigen Tagen akzeptierte einer von ihnen die Einreichung ohne weitere Rückfragen. Sie floss dann über einen anderen Entwickler zu Torvalds, der sie in die siebte Vorabversion von Linux 5.11 integriert. In der Patch-­Beschreibung hatten wir zudem eine Auszeichnung hinterlegt, die zum Backport in die vier neuesten Stable- und Longterm-­Kernel aufforderte. Daher hielt sie ohne weiteres Zutun nur drei Tage später, am 10. Februar, Einzug in die Kernel-Versionen 4.14.221, 4.19.175, 5.4.97 und 5.10.15.

Verteilung

Nutzer von Arch Linux und Fedora 32 und 33 erhielten Linux 5.10.15 innerhalb weniger Tage über die normale Systemaktualisierung; openSUSE Tumbleweed folgte etwas später. Die aktuelle Version von Debian GNU/Linux sollte die Änderung innerhalb einiger Wochen über den neuen 4.19er-Kernel bekommen.

Ubuntu 20.04 LTS dürfte den Work­around über den neuen 5.4er-Kernel erreichen. Ungewiss ist, ob Ubuntu 20.10 sie bekommt: Dessen Kernel basiert auf Linux 5.8, den die Kernel-Entwickler schon lange nicht mehr pflegen. Zukünftige Versionen von Ubuntu und die meisten anderen neuen Distributionsversionen werden die Sonderbehandlung über 5.11 und neuer erhalten.

Letztlich verschwindet das Problem damit aus der Welt – auch bei Nutzern, die von sporadischen Abstürzen durch das APST-Problem betroffen waren, aber der Sache nie nachgegangen sind oder die Ursache nicht finden konnten.

Ob die Änderung wirklich wirkt, ­können wir allerdings nach wie vor nicht gesichert sagen: Mit unmodifiziertem ­Kernel trat im Testlabor innerhalb von drei Wochen das Problem nie wie beschrieben auf. Und das, obwohl wir fast rund um die Uhr testeten – oftmals mit zwei PCs parallel und ab einem gewissen Zeitpunkt auch mit der betroffenen SSD, die uns der Leser freundlicherweise hat zukommen lassen. Bei den Versuchen haben wir Testumgebung und -verfahren mehrfach variiert, ohne dass es geholfen hat.

Ein anderer Leser stimmt uns indes optimistisch. Bei ihm stürzte Linux durch die A2000-Macke zwar nicht an jedem Tag ab, aber an vielen – und oftmals sehr schnell. Bei einem Kernel mit unserem Patch trat das Problem innerhalb von neun Tagen nicht einmal auf.

Richtige Lösung

Zu Ende ist die Geschichte damit (hoffentlich) noch nicht, schließlich ist der Patch nur ein Workaround: Er umgeht ein Problem, beseitigt aber nicht die eigentliche Ursache. Eine ordentliche Lösung sieht anderes aus, denn durch den Patch steigt die Leistungsaufnahme im Leerlauf – auch bei Systemen mit Kingston-SSDs der Serie, die das APST-Problem aus welchen ­Gründen auch immer nicht zeigen.

Zur ordentliche Lösung ist mehr Know-how nötig, daher ist Kingston gefragt. Dass die Firma ein Firmware-Update in Aussicht stellt, spricht immerhin dafür, dass die Ursache des Problems in der A2000-SSD steckt. Da es nach jetzigem Kenntnisstand nicht unter Windows auftritt, lässt sich aber auch nicht vollständig ausschließen, dass beim Linux-Kernel was im Argen liegt – derlei ist schon vorgekommen, doch die Indizien sprechen in diesem Fall dagegen.

Auch Linux kann allerdings nicht Hellsehen, daher wird es den tiefsten Stromsparmodus auch bei SSDs mit der neuesten Firmware meiden. Damit sich das ändert, muss der Kernel die Firmware-Version prüfen. Wenn es eine neue ist, könnte er den tiefsten APST-Modus wieder freigeben; falls nicht, müsste er ihn weiter links liegen­lassen und Nutzer idealerweise per Log-­Ausgabe auf die Problematik und die neue Firmware hinweisen. Das erfordert einen komplexeren Patch, den Kingston selbst beisteuern sollte. (thl@ct.de)

Kernel-Patch und Quirk-Text: ct.de/ywez