NVMe-I/O-Zeitüberschreitungen und Controller-Resets · Linux Fix Lab

Symptome und Geltungsbereich

Dateizugriffe stehen, während nvme Reset- oder Abbruchmeldungen protokolliert.
Ein NVMe-Namespace verschwindet bis zum Neustart.

Betroffene Umgebung

PCIe-NVMe-Speicher mit Linux-nvme-Treiber; NVMe over Fabrics benötigt zusätzliche Transportprüfungen.

Erkennbare Meldungen (synthetische Beispiele)

nvme nvme0: I/O 42 QID 2 timeout, reset controller

Zustands- und PCIe-Ereignisse vergleichen; dies allein beweist keinen Medienfehler.

nvme nvme0: Device not ready; aborting reset, CSTS=0x1

Unnötige Schreibzugriffe beenden und Daten sichern; Firmware, Stromversorgung und PCIe-Verfügbarkeit prüfen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Ein blockierter Controller, Firmwarefehler, Temperaturproblem, PCIe-Fehler oder eine Treiberregression kann die Fertigstellung verhindern.
Bei Resets nach Leerlauf oder Resume kann ein getrennter Energiesparvergleich nötig sein; Last-Resets allein identifizieren APST nicht.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Kernel-Ereignisse bei Bedarf mit Journalrechten lesen; NVMe-, PCIe/AER- und Dateisystemzeilen rund um den Vorfall erhalten.

journalctl -k -b --no-pager -n 400

Ergebnis einordnen: Ein Reset ist Fehlerbehandlung nach einem Befehlsproblem. Controller-not-ready oder ein Status aus ausschließlich Einsen ist ein deutlicherer Verfügbarkeitsfehler; fehlendes AER schließt PCIe-Probleme nicht aus.

Prüfschritt 2

/dev/nvme0 durch den Controller des betroffenen Namespace ersetzen. Zustand und Fehleraufzeichnungen lesen; kein Test startet.

sudo smartctl -x /dev/nvme0

Ergebnis einordnen: Medienfehler, Critical-Warning-Bits oder hohe aufgezeichnete Temperatur liefern konkrete Hinweise. Ein Error-Log-Zähler kann auch nicht unterstützte Admin-Befehle zählen und bedeutet nicht automatisch Medienschaden.

Nächste Schritte nach Befund

Unterstützten Kernel und SSD-Firmware vergleichen

Wenn der erste Ausfall auf ein Kernel-Update folgt, einen installierten zuvor funktionierenden Kernel mit derselben Last und ohne weitere Tuning-Änderungen starten. Treten Resets unter mehreren Kerneln auf, das genaue SSD-Modell mit Firmware-Hinweisen des Herstellers vergleichen.

Vorsicht: Zuerst Daten sichern und eine startfähige Alternative behalten. Einen eingebundenen Root-Controller nicht manuell zu Diagnosezwecken zurücksetzen.

Wiederherstellung / Rücknahme: Bei fehlgeschlagenem Vergleich den vorherigen Boot-Eintrag wählen. Firmware-Updates sind eventuell nicht reversibel; Wiederherstellung aus Backup bleibt erforderlich.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Physischen NVMe-Pfad prüfen

Wenn Ausfälle mit AER-Meldungen oder Hitze zusammenfallen, ausschalten und SSD-Sitz, Kühlerkontakt und Adapteranordnung prüfen. Jeweils nur einen unterstützten Slot oder Adapter vergleichen und beobachten, ob dieselben Fehler wiederkehren.

Vorsicht: Keine Benchmarks auf Speicher durchführen, der bereits nicht korrigierbare Fehler liefert. Slotwechsel können Boot-Reihenfolge und PCIe-Lane-Aufteilung beeinflussen.

Wiederherstellung / Rücknahme: Bei schlechterer Erkennung im ausgeschalteten Zustand die dokumentierte Hardwareanordnung und Firmware-Boot-Reihenfolge wiederherstellen.