USB-Selective-Suspend-Debugging: Zufällige Disconnects, Sleep-Resume-Fehler und verpasste Transfers

USB Selective Suspend soll Strom sparen. Wenn es funktioniert, treten idle Devices in einen Low-Power-State und resumed bei Bedarf. Wenn es scheitert, sehen Nutzer zufällige Disconnects, fehlende Daten, eingefrorene Kameras, Serial-Ports, die nicht antworten, HID-Devices, die Input verpassen, oder Devices, die nach Sleep verschwinden. Suchen wie "USB selective suspend random disconnect", "USB device stops working after idle", "USB resume failure" und "disable USB selective suspend" kommen meist von Leuten, die bereits Kabel und Treiber versucht haben.

Selective Suspend zu deaktivieren kann ein Workaround sein, ist aber keine Diagnose. Die echte Frage ist, ob das Device, der Treiber, der Hub, der Host-Controller oder die App während Suspend/Resume oder Idle-Recovery versagt.

Bus Scope hilft, weil der Fehler eine Timeline hat. Sie müssen wissen, welcher Traffic vor dem Idle passierte, ob der Host den Pfad suspendiert hat, welcher Request das Device resumed hat und welcher Transfer nach dem Resume fehlgeschlagen ist.

Was Selective Suspend tut

Selective Suspend erlaubt dem OS, ein einzelnes USB-Device oder Interface zu suspendieren, während der Rest des Systems aktiv bleibt. Das ist anders als voller System-Sleep. Ein USB-Device kann suspendiert werden, weil es idle wirkt, selbst wenn der Computer sonst wach ist.

Das zählt für:

• USB-Serial-Adapter
• HID-Devices
• USB-Kameras
• Audio-Schnittstellen
• Debug-Probes
• Security-Tokens
• Custom-Vendor-Devices
• Bus-Powered-Sensoren

Behandelt die Device-Firmware Suspend/Resume nicht korrekt, kann der erste Transfer nach Idle fehlschlagen.

Typische Symptome

Selective-Suspend-Issues sehen oft so aus:

• Device läuft nach Anstecken, aber scheitert nach ein paar Minuten.
• Erstes Kommando nach Idle timed out.
• Serial-Read blockiert nach Inaktivität ewig.
• Kamera-Preview friert nach Bildschirmsperre ein.
• HID-Reports stoppen bis Unplug/Replug.
• Device reconnettet mit neuer Adresse.
• App sagt Device disconnected, obwohl es physisch noch angeschlossen ist.
• Windows- oder Linux-Logs zeigen Reset- oder Resume-bezogene Meldungen.

Das Schlüssel-Muster ist Zeit. Folgt der Fehler Idle-Perioden, Sleep/Resume, Display-off oder Laptop-Power-State-Änderungen, gehört Power-Management in die Untersuchung.

Suspend-Fehler vs. Resume-Fehler

Es gibt zwei unterschiedliche Probleme:

• Suspend-Fehler: das Device oder der Treiber kann nicht korrekt in Low-Power eintreten.
• Resume-Fehler: das Device tritt in Low-Power, kehrt aber nicht korrekt zurück.

Aus User-Sicht können beide wie "device disconnected" aussehen. Der USB-Trace kann sie trennen, indem er zeigt, ob der Traffic sauber stoppte und ob der nächste Request nach Idle fehlschlug.

Verschwindet das Device nur, nachdem die App nach Idle ein Kommando sendet, sind Resume oder Firmware-State-Restoration verdächtig. Resettet das Device während Idle ohne App-Request, sind Host-Power-Management, Hub-Verhalten oder Device-Firmware-Watchdog verdächtig.

Erster Transfer nach Idle

Der erste Transfer nach Idle ist oft die wichtigste Evidence. Es kann sein:

• ein Control-Request.
• ein Bulk-Read oder -Write.
• ein Interrupt-IN-Poll.
• ein klassenspezifischer Request.
• ein Vendor-Kommando.
• ein Stream-Restart-Request.

Timed der erste Transfer aus, stalled oder triggert einen Reset, ist das Device wahrscheinlich nicht in den erwarteten State resumed. Der Fix kann Firmware-Resume-Handling, Treiber-Power-Policy, App-Retry-Verhalten oder das Deaktivieren von Selective Suspend für dieses Device sein.

Runtime Power Management unter Linux

Linux hat ebenfalls USB-Runtime-Power-Management. Devices können nach einem Idle-Delay autosuspend. Ein Device kann sich je nach Treiber, Kernel-Version, Autosuspend-Settings und ob eine App das Device offen hält, unterschiedlich verhalten.

Für Linux-Untersuchungen capturen Sie den Traffic und korrelieren mit System-Logs. Resumed das Device und resettet sofort, ist der Bus-Trace nützlicher als ein generischer "I/O error" aus der App.

Windows Selective Suspend

Unter Windows hängt das Selective-Suspend-Verhalten von Power-Plan, Treiber-Support, USB-Hub-Settings und Device-Klasse ab. Nutzer deaktivieren oft "USB selective suspend setting" in den Power-Optionen. Das kann ein praktischer Workaround sein, aber eine professionelle Diagnose sollte trotzdem erklären, ob das Device während Idle-Recovery gescheitert ist.

Windows-USB-Issues können auch durch Modern Standby, Laptop-Dock-Verhalten, Hubs und Host-Controller-Treiber beeinflusst werden. Ein Device kann auf einem Desktop laufen, aber auf einem Laptop-Dock scheitern, weil sich das Suspend- und Resume-Verhalten unterscheidet.

Capture-Strategie

Um einen Selective-Suspend-Bug zu capturen:

1. Capture starten, während das Device läuft.
2. Eine bekanntermaßen erfolgreiche Operation durchführen.
3. Das Device lange genug idle lassen, um das Issue zu triggern.
4. Die Operation durchführen, die normalerweise fehlschlägt.
5. Capture durch Timeout, Reset oder Reconnect fortsetzen.
6. Das volle Timing-Fenster speichern.

Starten Sie den Capture nicht erst, nachdem das Device bereits gescheitert ist. Sie brauchen den Übergang von aktiv zu idle zum Fehler.

Was zu prüfen ist

Im Trace inspizieren:

• Letzter Transfer vor Idle.
• Zeit-Gap vor dem Fehler.
• Erster Transfer nach Idle.
• Timeout, Stall, Reset oder Disconnect.
• Re-Enumeration nach Fehler.
• Änderung der Device-Adresse.
• Klassenspezifischer Request nach Resume.
• Endpoint-Halt-Recovery.
• Alternate-Setting-Wechsel für Streaming-Devices.

Timing ist hier kein Rauschen. Timing ist die Evidence.

Debug-Checkliste

Nutzen Sie diese Reihenfolge:

1. Bestätigen, ob Fehler mit Idle-Zeit korrelieren.
2. An AC-Power und Battery-Power testen.
3. Direkter Port vs. Hub oder Dock testen.
4. Vor Idle und durch den Fehler hindurch capturen.
5. Den ersten fehlgeschlagenen Transfer nach Idle identifizieren.
6. Prüfen, ob das Device resettet oder nur ein Transfer fehlschlägt.
7. Mit deaktiviertem Selective Suspend vergleichen.
8. Anderes OS oder anderen Host-Controller vergleichen.
9. Firmware-Resume-Handling prüfen.
10. Treiber-Power-Policy und App-Retry-Verhalten prüfen.

Enddiagnose

USB-Selective-Suspend-Probleme werden durch Raten nicht gut gelöst. Power-Management zu deaktivieren mag Symptome reduzieren, aber die echte Engineering-Antwort kommt aus der USB-Timeline: aktiver Traffic, Idle-Gap, Resume-Versuch, fehlgeschlagener Transfer, Reset oder Recovery.

Bus Scope hilft, diese Evidence zu bewahren und zu inspizieren, sodass ein "random USB disconnect" als spezifischer Suspend/Resume-, Treiber-, Firmware-, Hub- oder Power-Management-Fehler diagnostiziert werden kann.