Geräterückmeldung bricht System-Suspend ab · Linux Fix Lab

Symptome und Geltungsbereich

Der Suspend-Aufruf kehrt sofort zur laufenden Sitzung zurück.
PM-Meldungen nennen ein scheiterndes Gerät oder einen asynchronen Suspend-Fehler.

Betroffene Umgebung

Linux-System-Suspend über Kernel-PM; dieser Eintrag betrifft abgelehnten Geräte-Suspend statt eines reinen Compositor-Schwarzbilds.

Erkennbare Meldungen (synthetische Beispiele)

usb 1-2: PM: failed to suspend async: error -16

Frühere treiberspezifische Meldung und Geräteadresse finden; Gesamtfehler allein erklärt keinen Treiber- oder Firmware-Auslöser.

Mögliche Ursachen

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

Ein Treiber kann sein Gerät nicht ruhigstellen oder benötigt fehlende Einbindung.
Plattform- oder Geräte-Firmware kann nach Regression den Übergang ablehnen; erfolgreich erreichter Schlafzustand mit anschließendem Aufwachen ist ein anderer Pfad.

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

Übergangsstufen und Rückmeldungen bei Bedarf mit Administrator-Journalzugriff lesen.

journalctl -b -k --no-pager --grep='PM:|suspend|dpm_run_callback'

Ergebnis einordnen: Ersten Gerätefehler vor der PM-Gesamtmeldung bestimmen. suspend entry mit anschließendem Fehler beweist keinen tatsächlich erreichten Hardware-Schlaf.

Prüfschritt 2

Unterstützte Varianten von Suspend-to-Memory lesen; Klammern markieren Auswahl. Dies löst keinen Schlaf aus.

cat /sys/power/mem_sleep

Ergebnis einordnen: Nur vom Kernel/der Plattform gelistete Modi sind verfügbar. Aktueller Modus hilft beim Vergleich, doch Wechsel repariert nicht automatisch scheiternde Geräterückmeldung.

Nächste Schritte nach Befund

Optionales scheiterndes Gerät eingrenzen

Nennt der erste PM-Fehler ein optionales USB-Gerät oder dessen Arbeitslast, Arbeit sicher stoppen und Gerät vor kontrolliertem Suspend-Test trennen. Notwendige Treiber nicht allein anhand der letzten Fehlerzeile entladen.

Vorsicht: Arbeit speichern, Wechselmedien normal aushängen und lokal testen. Ein reiner Fernzugriffstest kann Wiederherstellung unerreichbar machen.

Wiederherstellung / Rücknahme: Gerät und Arbeitslast bei Bereitschaft wieder verbinden; bei reproduzierbarer Blockade bis zu unterstützter Korrektur getrennt lassen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

PM-Einbindung des ermittelten Treibers korrigieren

Dokumentiert betroffener Treiber nötige Schlaf-Hooks oder passende Korrektur, dessen Distributionseinbindung abgleichen oder unterstützten korrigierten Kernel vergleichen. Fortgeschrittene pm_test-Stufen gehören in geplante lokale Diagnose nach Kernel-Anleitung.

Vorsicht: pm_test nicht versehentlich aktiv lassen und nicht alle Weckquellen abschalten. Ein Stufentest kann hängen und darf nicht mit ungesicherter Arbeit laufen.

Wiederherstellung / Rücknahme: Vorheriges Treiberpaket/Starteintrag und dokumentierte Schlaf-Einstellungen wiederherstellen; nach geführtem Test pm_test bei Änderung auf none zurückstellen.