[erledigt] Kein Suspend beim verschlüsselten System

[Ulidor]

Hallo,

ich bin mit meinem System (Buster) vom PC auf den Laptop (Tuxedo Book BC1506) umgezogen. Auf dem PC funktioniert der Suspend-Modus einwandfrei.
Wenn ich auf dem Laptop

Code: Alles auswählen

# systemctl suspend

eingebe, wird der Bildschirm sofort dunkel, aber die Tataturbeleuchtung wird nicht abgeschaltet und die Status-LED leuchtet weiterhin dauerhaft, anstatt zu blinken. Drücke ich den Einschaltknopf, kommt ein grafischer Anmeldeprompt (aber nicht der, der beim Wiederanmelden nach dem Abmelden kommt). Wenn ich das Passwort eingebe, kann ich normal weiterarbeiten.

dmesg zeigt mir nach dem Wiederanmelden u.a. Folgendes:

Code: Alles auswählen

[ 1615.348788] wlp1s0: deauthenticating from d4:3f:cb:91:87:62 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 1615.650359] PM: suspend entry (deep)
[ 1615.662740] Filesystems sync: 0.012 seconds
[ 1615.662827] (NULL device *): firmware: direct-loading firmware i915/skl_dmc_ver1_27.bin
[ 1615.662913] (NULL device *): firmware: direct-loading firmware regulatory.db
[ 1615.662915] (NULL device *): firmware: direct-loading firmware regulatory.db.p7s
[ 1615.662930] (NULL device *): firmware: direct-loading firmware intel/ibt-12-16.ddc
[ 1615.663053] (NULL device *): firmware: direct-loading firmware intel/ibt-12-16.sfi
[ 1615.663341] (NULL device *): firmware: direct-loading firmware iwlwifi-8265-36.ucode
[ 1615.798345] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 1615.800318] OOM killer disabled.
[ 1615.800318] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 1615.801475] printk: Suspending console(s) (use no_console_suspend to debug)
[ 1616.538615] DMAR: DRHD: handling fault status reg 2
[ 1616.538619] DMAR: [DMA Read] Request device [03:00.0] PASID ffffffff fault addr 0 [fault reason 06] PTE Read access is not set
[ 1616.558004] xhci_hcd 0000:03:00.0: WARN: xHC save state timeout
[ 1616.558012] PM: suspend_common(): xhci_pci_suspend+0x0/0x140 [xhci_pci] returns -110
[ 1616.558020] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -110
[ 1616.558023] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -110
[ 1616.558024] PM: Device 0000:03:00.0 failed to suspend async: error -110
[ 1616.816588] PM: Some devices failed to suspend, or early wake event detected

Ich poste hier nur die Zeilen, die mir wichtig zu sein scheinen, denn alle Zeilen, die mit „DMAR:" und mit „PM:" beginnen, sind rot. Nur sagen sie mir leider nichts.

Suspend funktioniert auf dem Laptop eigentlich einwandfrei, denn bei einem zweiten, nahezu unverändertem Buster klappt es ohne Probleme. Es scheint also bei der Migration was schief gegangen zu sein. Im Wesentlichen habe ich dabei folgende Schritte durchgeführt:

Buster mit unverschlüsselter /boot-Partition, verschlüsselter /-Partition und verschlüsselter Swap-Partition auf dem Laptop installiert.

Das neue System gestartet, von der grafischen Oberfläche (KDE-Plasma) abgemeldet, auf zweiter Konsole als root angemeldet.

Die externe USB-Backup-SSD vom PC angeschlossen und gemountet.

Im neusten Backup als root ein Bash-Skript gestartet, dass nacheinander folgende Befehle ausgeführt hat („$basedir" ist das Basisverzeichnis des Backups):

Code: Alles auswählen

rsync -aHAX $basedir/etc/apt /etc
apt-get update
apt-get -t bullseye-backports install apt-clone
apt-clone restore $basedir/root/apt-clone-state-ulidor.tar.gz
apt install openssh-server   
cp -a $basedir/etc/fstab /etc/fstab_extern
cp -a $basedir/etc/udev/rules.d/10-custom.rules /etc/udev/rules.d/
cp -a $basedir/etc/systemd/system/backup.service /etc/systemd/system/
cp -a $basedir/etc/rc.local /etc/
cp -a $basedir/usr/local/irtrans /usr/local/
systemctl daemon-reload
systemctl enable backup
rsync -aHAX --delete $basedir/root/ /root
rsync -aHAX --delete $basedir/home/ /home
rsync -aHAX --delete $basedir/usr/local/bin/ /usr/local/bin
rsync -aHAX --delete $basedir/usr/local/sbin/ /usr/local/sbin
cat $basedir/root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

Alle Befehle liefen einwandfrei durch.

Hat jemand eine Idee, wo das Problem mit Suspend liegen könnte?

[Blackbox]

Beim Überfliegen der Logmeldung ist mir aufgefallen, dass dein USB-Backend in einen Timeout rennt, dazu sollte es Meldungen im Logfile geben, die mehr Klarheit bringen.

[Ulidor]

Danke, Blackbox, damit bin ich schon mal weiter gekommen. Wie und wo sollte ich am besten nach weiteren Logmeldungen suchen?

Auf deinen Hinweis hin habe ich diesen Link gefunden:
https://bbs.archlinux.org/viewtopic.php?id=242236
Da geht es allerdings um einen Workaround mit zwei Systemd-Units. Das wäre umständlich. Und es muss ja einen Grund geben, warum Suspend mit einem frisch installiertem Buster auf diesem Laptop funktioniert, mit meinem an mein PC-System angepasstem Buster aber nicht.

Zum Testen habe ich trotzdem mal die Befehle in den Systemd-Units aus dem Link ausprobiert:

Code: Alles auswählen

echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind

Danach funktionierte das Suspend einwandfrei.
Nach dem Wiederaufwachen funktionierte USB natürlich nicht mehr.

Dann:

Code: Alles auswählen

echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind

Danach funktionierte USB wieder.
Nun hätte ich erwartet, dass Suspend wieder nicht mehr geht. Aber seltsamerweise funktioniert es dann trotzdem.

[Blackbox]

Ich würde im Journal nach Meldungen vom USB Backend suchen.

[Ulidor]

Ich würde im Journal nach Meldungen vom USB Backend suchen.

Mit journalctl und dann nach Zeilen mit xhci_hcd suchen oder was ist am besten?

Ich habe jetzt mal die beiden echo-Befehle in /etc/rc.local eingetragen. Nach einem Neustart funktionieren USB und Suspend einwandfrei. Aber das wäre ja auch nur ein Workaround und löst das Problem nicht wirklich.

[Ulidor]

Was mir jetzt noch aufgefallen ist: Wenn ich die beiden echo-Befehle eingegeben habe, funktioniert Suspend auch nach einem Warmstart, ohne dass die Befehle erneut eingegeben werden müssen. Erst nach einem Kaltstart geht Suspend dann nicht mehr.

[Blackbox]

Wie gesagt, mit Beschreibungen kann man nichts anfangen!
Bitte konkrete Meldungen aus deinem Journal liefern, nachdem du deine Aktionen erfolgreich/-los absetzen konntest.

[Ulidor]

Der erfolglose Suspend-Versuch startete um 19:37:00, um 19:37:15 habe ich die Powertaste gedrückt, um den halb eingeschlafenen Laptop wieder aufzuwecken:
https://nopaste.debianforum.de/41892

Nach der Eingabe von

Code: Alles auswählen

# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind

startete der erfolgreiche Versuch um 19:51:00, um 19:51:15 habe ich die Powertaste gedrückt:
https://nopaste.debianforum.de/41893

[Blackbox]

Code: Alles auswählen

Apr 20 19:37:03 ulidorx kernel: PM: Device 0000:03:00.0 failed to suspend async: error -110

Das folgende Gerät wirft einen Fehler.

Code: Alles auswählen

Apr 20 19:37:16 ulidorx kernel: xhci_hcd 0000:03:00.0: xHC error in resume, USBSTS 0x401, Reinit

Etwas weiter unten wird dann auch gleich aufgelöst, um welches Gerät es sich handelt.
Liegt hier eventuell ein Hardwaredefekt vor?

Code: Alles auswählen

Apr 20 19:51:17 ulidorx kernel: xhci_hcd 0000:03:00.0: xHC error in resume, USBSTS 0x401, Reinit

Da dieser Fehler auch nach deinen Änderungen im sysfs auftritt, würde ich einen Hardwaredefekt nicht mehr ausschließen wollen.
Kannst du diese Schnittstelle zu Testzwecken deaktivieren?

[Ulidor]

Kannst du diese Schnittstelle zu Testzwecken deaktivieren?

Hm, mache ich das nicht schon mit dem echo-Befehl (unbind)?

Und wenn es ein Hardwaredefekt sein sollte (der bisher bei der Benutzung von USB keine Probleme macht), wäre ja noch immer die Frage, warum es bei dem anderen, nahezu unveränderten Buster auf diesem Laptop keine Probleme mit Suspend gibt. Soll ich auch von dem anderen Buster mal ein Journal posten?

[Blackbox]

Soll ich auch von dem anderen Buster mal ein Journal posten?

Das wäre zumindest ein weiterer Schritt, um diesen merkwürdigen Fehler einzugrenzen.

Eine weitere Möglichkeit wäre, dein System auf Debian 12 zu aktualisieren, dieses befindet sich in den letzten Zügen der Fertigstellung und läuft bereits recht problemlos.
Mit etwas Glück ist dieser Fehler mit einem neueren Kernel gefixt, und du profitierst bereits von recht aktueller Software.
Kannst du dir diesen Weg vorstellen?

[Ulidor]

In den nächsten Tagen möchte ich erst noch etwas anderes versuchen:

Ich installiere Debian 11 noch mal neu auf dem Laptop als verschlüsseltes System, wie im Eingangsposting beschrieben.
Dann teste ich erst mal, ob Suspend in dieser Installation funktioniert.
Wenn ja, schließe ich die Backup-USB-SSD vom PC am Laptop an und starte das im Eingangsposting erwähnte Bash-Skript.
Das Skript zeigt jeden Befehl vor dem Ausführen an und fragt, ob der Befehl ausgeführt werden soll. Nach jedem Befehl (jedenfalls, wo es sinnvoll ist) teste ich Suspend.

Wäre das sinnvoll?

[Blackbox]

Ich installiere Debian 11 noch mal neu auf dem Laptop als verschlüsseltes System, wie im Eingangsposting beschrieben.

Wenn ich vor dieser Entscheidung stände, wäre mein Griff so kurz vor einem Release sehr wahrscheinlich zum künftigen Debian 12.

[Ulidor]

Ich wollte jetzt doch gerne sehen, ob der Fehler mit meinem Bash-Skript zu tun hat, deshalb habe ich Debian 11 nach der im Eingangsposting geschilderten Art noch mal neu auf dem Laptop installiert.

Nach dem Start des frisch installierten Systems habe ich mich in einem Konsolenfenster unter Plasma als root angemeldet und den Befehl

Code: Alles auswählen

# systemctl suspend

eingegeben.
Das Suspend misslang und es tauchten im Journal, so weit ich das auf den ersten Blick erkennen konnte, die gleichen Fehlermeldungen auf.

Das Debian 11 auf diesem Laptop, bei dem Suspend funktioniert, ist komplett auf einer unverschlüsselten Partition plus Swap-Partition, während das frisch installierte Debian 11 auf einer unverschlüsselten /boot-Partition und einer verschlüsselten Root-Partition plus verschlüsselter Swap-Partition installiert ist.
Kann es also mit der Verschlüsselung zu tun haben, dass Suspend nicht ohne Tricks funktioniert?


Und jetzt habe ich das Gleiche wie oben beschrieben mit Debian 12 ausprobiert: Das Verhalten ist genau das gleiche. Auch, dass Suspend nach den zwei Befehlen

Code: Alles auswählen

# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind

erst mal funktioniert.


Anscheinend hat mein Laptop wirklich eine seltsame Macke.
Oder haben verschlüsselte Systeme (zumindest Debian 11 und 12) auf Laptops grundsätzlich dieses Problem? Ich habe jedenfalls noch nie davon gehört.

[Blackbox]

Anscheinend hat mein Laptop wirklich eine seltsame Macke.

Meine Interpretation deiner Meldungen im Logfile würde ich als Hardwareproblem deuten, deswegen fragte ich, ob du die betroffene Schnittstelle deaktivieren kannst?

[Ulidor]

Meine Interpretation deiner Meldungen im Logfile würde ich als Hardwareproblem deuten, deswegen fragte ich, ob du die betroffene Schnittstelle deaktivieren kannst?

Wird sie denn nicht mit

Code: Alles auswählen

# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind

deaktiviert?
Dann funktioniert USB aber nicht mehr.

Wie es aussieht, muss ich wohl mit dem Workaround auf dem Laptop leben, wenn das System darauf verschlüsselt sein soll.

[Blackbox]

Wird sie denn nicht mit

Code: Alles auswählen

# echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind

deaktiviert?

Ich bin mir eben auch nicht wirklich sicher, welche Auswirkungen dieser Befehl im Endeffekt hat.
Kannst du diese USB Schnittstelle nicht im BIOS/UEFI deaktivieren?
Mit etwas Glück kannst du nur den defekten USB-Anschluss deaktivieren.

Dann funktioniert USB aber nicht mehr.

Das ist die logische Konsequenz der Deaktivierung.

Wie es aussieht, muss ich wohl mit dem Workaround auf dem Laptop leben, wenn das System darauf verschlüsselt sein soll.

Nicht schön, aber alle anderen Möglichkeiten wären deutlich aufwendiger, oder sogar teurer.

Von welcher Hardware schreiben wir eigentlich die ganze Zeit?

[Ulidor]

Dann funktioniert USB aber nicht mehr.

Das ist die logische Konsequenz der Deaktivierung.

Ich kann es nicht deaktivieren, denn schon allein, wenn ich den Befehl absetze, wird kein USB-Grät mehr auch nur erkannt. Ich brauche aber USB.

Wie es aussieht, muss ich wohl mit dem Workaround auf dem Laptop leben, wenn das System darauf verschlüsselt sein soll.

Nicht schön, aber alle anderen Möglichkeiten wären deutlich aufwendiger, oder sogar teurer.

Der Workaround mit /etc/rc.local funktioniert doch nicht, wie ich nun festgestellt habe. Ich hatte beim Test die Befehle auf der Kommandozeile abgesetzt, dann die rc.local erstellt und anschließend wohl einen Warmstart durchgeführt. Da wusste ich noch nicht, dass nach dem Absetzen der Befehle Suspend auch nach einem Warmstart noch funktioniert.
Ich muss wohl doch mal den Workaround mit den systemd-Units versuchen.

Von welcher Hardware schreiben wir eigentlich die ganze Zeit?

Das müsste ich mal genauer untersuchen. So weit ich weiß, sind die USB-Schnittstellen in dem Laptop von Intel.

[Blackbox]

So weit ich weiß, sind die USB-Schnittstellen in dem Laptop von Intel.

Mir würde vorerst auch der Name des Notebooks ausreichen, dann könnte man mal in dessen Handbuch schauen.

[Tintom]

Es gibt bei systemd die Möglichkeit vor bzw. nach dem Wechsel des Energiezustands Skripte auszuführen (Hervorhebungen von mir):

Direkt vor dem Eintritt in die Systemsuspendierung und/oder den Systemruhezustand wird systemd-suspend.service (und die anderen erwähnten Units) alle in /lib/systemd/system-sleep/ befindlichen Programme ausführen und ihnen zwei Argumente übergeben. Das erste Argument wird »pre«, das zweite entweder »suspend«, »hibernate«, »hybrid-sleep« oder »suspend-then-hibernate«, abhängig von der ausgewählten Aktion, sein. Direkt nach Verlassen der Systemsuspendierung und/oder des Ruhezustandes werden die gleichen Programme ausgeführt, aber das erste Argument ist jetzt »post«. Alle Programme in diesem Verzeichnis werden parallel ausgeführt und mit der Ausführung der Aktion wird nicht fortgefahren, bis alle Programme sich beendet haben.

Wenn ich das Problem richtig verstehe, sollte ein kleines Skript in dem o.g. Ordner als Notbehelf reichen:

Code: Alles auswählen

#!/bin/sh
if [ "${1}" == "pre" ];
then
	echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
else
	echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
fi

Kannst du das testen?

Da du ein Tuxedo-Notebook hast, könntest du auch einfach bei denen anfragen, ob die noch eine Idee haben wieso das auftritt und ob es einen anderen Lösungsweg gibt.

[Blackbox]

Tatsache, du hast im ersten Post dieses Threads geschrieben, welche Hardware du zum Einsatz bringst.
Das habe ich völlig überlesen, ansonsten hätte ich dir auch empfehlen, dich beim Tuxedo Computers Support zu melden.
Bin selbst Inhaber einer BU.

[Ulidor]

Kannst du das testen?

Ja, das klappt hervorragend!

Allerdings musste ich das Skript etwas abändern:

Code: Alles auswählen

#!/bin/sh

if [ "$1" = "pre" ]
then
	echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
else
	echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind
fi

Ich weiß jetzt auch, warum mein erhoffter Workaround mit /etc/rc.local nicht funktioniert hat: Das Ausführen beider echo-Befehle hintereinander führt nur dann zum Erfolg, wenn es vor dem ersten echo-Befehl einen (misslungenen) Suspend-Versuch gegeben hat. Deshalb geht es eigentlich nur so, dass vor dem Suspend der echo-Befehl mit unbind und nach dem Suspend der mit bind ausgeführt wird.
Ein super Workaround, vielen Dank!

Tatsache, du hast im ersten Post dieses Threads geschrieben, welche Hardware du zum Einsatz bringst.

Kein Ding, es geht ganz schnell, dass man mal was überliest.

Ich kann jedenfalls damit leben, wie es jetzt ist.
Okay, ich könnte auch mal bei Tuxedo nachfragen. Ich habe mit deren Support bisher noch keine Erfahrung. Aber die Kiste ist immerhin schon sechs Jahre alt.
Ich kann jedenfalls damit leben, wie es jetzt ist.

[Ulidor]

Dann könnte ich ja jetzt den Thread als „erledigt" kennzeichnen.

Sollte ich auch den Betreff ändern? Ich war ja davon ausgegangen, dass ich bei der Migration vom PC auf den Laptop was falsch gemacht hatte. Aber es hat ja anscheinend irgendwas mit der Verschlüsselung zu tun. Ein Betreff wie „Kein Suspend beim verschlüsselten System" wäre passender.
Oder wäre eine nachträgliche Änderung verwirrend?

[heisenberg]

Ein Betreff wie „Kein Suspend beim verschlüsselten System" wäre passender. Oder wäre eine nachträgliche Änderung verwirrend?

Ein Anliegen bei diesem Forum ist ja auch das Sammeln von Wissen, um das anderen Personen, mit dem gleichen Anliegen leicht auffindbares Wissen bieten zu können. Insofern ist eine Korrektur auf jeden Falll sinnvoll.

[Tintom]

Aber es hat ja anscheinend irgendwas mit der Verschlüsselung zu tun.

Wie kommst du darauf?