USB Remote Wakeup und Suspend-Resume-Debugging

USB-Power-Management-Bugs sind schwer zu diagnostizieren, weil das Device perfekt laufen kann, solange das System aktiv ist, aber erst nach Idle, Sleep, Selective Suspend, Dock-Sleep, Laptop-Lid-Close oder Monitor-Power-Off scheitert. Nutzer suchen nach "USB remote wakeup not working", "USB selective suspend disconnect", "USB device does not wake computer", "USB resume failure", "USB suspend resume bug" und "HID keyboard wake from sleep not working".

Bus Scope hilft, weil Suspend und Resume Bus-Level-Events sind, nicht nur App-Fehler. Sie müssen sehen, ob der Host das Device suspendiert hat, ob Remote-Wakeup aktiviert war, ob das Device Resume signalisiert hat, ob der Host den Traffic resumed hat und ob das Device re-enumeriert hat statt zu resumed.

Was Remote-Wakeup bedeutet

Remote-Wakeup erlaubt einem suspendierten USB-Device, den Host zu bitten, die Kommunikation wieder aufzunehmen. Häufige Beispiele:

• Tastatur weckt einen schlafenden Desktop.
• Maus weckt einen Laptop aus Idle.
• Dock-Button weckt eine Workstation.
• Barcode-Scanner weckt einen Kiosk.
• Industrieller Controller weckt einen Panel-PC.
• HID-Sensor weckt einen Host nach einem externen Event.

Remote-Wakeup ist nicht einfach "das Device hat Strom". Der Host muss es erlauben, das Device muss Support annoncieren, das Feature muss aktiviert sein und das Resume-Signaling muss zur richtigen Zeit kommen.

Häufige Symptome

Remote-Wakeup- und Suspend-Issues sehen so aus:

• Device läuft, bis der PC schläft.
• Device weckt den Computer nicht.
• Device weckt das System sofort nach Suspend.
• Device verschwindet nach Resume.
• Device re-enumeriert mit neuer Adresse.
• HID-Input wird nach Idle verpasst.
• Serial-Device hört nach Selective Suspend auf zu senden.
• Audio- oder Kamera-Device kommt ohne Daten aus Sleep zurück.
• Firmware recoveret erst nach Unplug/Replug.

Diese Symptome werden oft dem Treiber zugeschrieben, aber der Capture kann ein Firmware-Power-State-Problem zeigen.

Deskriptor- und Feature-Evidence

Der Configuration-Deskriptor kann Remote-Wakeup-Capability annoncieren. Der Host kann dann das Remote-Wakeup-Feature aktivieren oder deaktivieren. Ein nützlicher USB-Diagnose-Trace beantwortet:

• Wirbt das Device mit Remote-Wakeup?
• Hat der Host SET_FEATURE(DEVICE_REMOTE_WAKEUP) gesendet?
• Hat der Host das Feature später gecleart?
• Ist Suspend nach Idle eingetreten?
• Hat das Device versucht, Resume zu signalisieren?
• Hat der Host normale Transfers resumed?

Ohne diese Fakten ist die Diagnose Rätselraten.

Selective Suspend

Selective Suspend erlaubt dem OS, ein idle USB-Device zu suspendieren, ohne das ganze System in Sleep zu versetzen. Das spart Strom, legt aber Firmware-Bugs offen.

Fehler-Patterns:

• Device tritt in Low-Power-State, stellt aber Endpoint-State nicht wieder her.
• Firmware verliert pending Interrupt-IN-State.
• Device NAKt nach Resume ewig.
• Host resettet das Device nach Timeout.
• App sieht Timeout oder Device-Removal.
• Composite-Device resumiert ein Interface, aber nicht ein anderes.

Suchende tippen oft "USB selective suspend random disconnect", weil das Device disconnected zu sein scheint, obwohl das echte Event ein Suspend/Resume-Fehler ist.

Resume vs. Re-Enumeration

Nach Sleep gibt es zwei sehr unterschiedliche Outcomes:

• Resume: dasselbe Device läuft mit bestehender Konfiguration weiter.
• Re-Enumeration: Host resettet und enumeriert das Device neu.

Re-Enumeration ist nach physischem Disconnect akzeptabel, aber nach normalem Suspend verdächtig. Sie kann Apps zerbrechen, die offene Handles, Serial-Port-Namen, HID-Pfade oder Kamera-Capture-Sessions halten.

Bus Scope sollte helfen, zu identifizieren, ob der Trace normalen Resume-Traffic oder eine neue Enumeration-Sequenz mit GET_DESCRIPTOR, SET_ADDRESS und SET_CONFIGURATION enthält.

Verpasste Wake-Events

Manchmal sieht das Device das externe Event, aber der Host wacht nicht auf. Ursachen:

• Remote-Wakeup nicht annonciert.
• Remote-Wakeup nicht vom Host aktiviert.
• Device sendet Resume zu früh.
• Device sendet Resume zu spät.
• Hub blockiert oder mishandelt Wake-Signaling.
• BIOS- oder OS-Wake-Policy deaktiviert den Port.
• Device-Firmware tritt in tieferen Sleep als erwartet.
• Event passiert, bevor Suspend abgeschlossen ist.

Paket-Level-Evidence ersetzt keine OS-Power-Policy, aber sie engt die Frage ein. Hatte das Device Berechtigung, den Host zu wecken, und hat es das versucht?

Sofortiges Wake nach Suspend

Das Gegenproblem ist ebenfalls häufig: Das System suspendiert und wacht sofort wieder auf. USB-Devices können das verursachen, wenn sie aufgrund von stale Input, noisy Interrupt-State, Debounce-Bugs oder Firmware, die Suspend als neues Event behandelt, Wake signalisieren.

Zu sammelnde Evidence:

• Letzter Interrupt-Report vor Suspend.
• Ob der Host Wake aktiviert hat.
• Timing zwischen Suspend und Resume.
• Device-Klasse und Interface.
• Ob derselbe Endpoint pending Daten hatte.
• Ob das Event bei jedem Suspend-Versuch wiederholt wird.

Das ist besonders häufig bei Tastaturen, Mäusen, Touch-Panels, Game-Controllern und Custom-HID-Devices.

Debug-Checkliste

Nutzen Sie diesen Ablauf:

1. Enumeration ab Anstecken capturen.
2. Remote-Wakeup-Capability in Deskriptoren bestätigen.
3. Prüfen, ob der Host Remote-Wakeup aktiviert.
4. Idle-Periode vor Suspend aufzeichnen.
5. Suspend-Timing identifizieren.
6. Nach Resume-Signaling oder Host-Resume-Traffic suchen.
7. Resume von voller Re-Enumeration trennen.
8. Endpoint-Verhalten nach Resume prüfen.
9. Dasselbe Device auf direktem Port und durch Hub vergleichen.
10. Sowohl Pre-Suspend- als auch Post-Resume-Pakete bewahren.

Enddiagnose

USB-Remote-Wakeup- und Suspend/Resume-Bugs sind Power-State-Protokoll-Probleme. Die nützliche Evidence ist Deskriptor-Capability, Host-Feature-Auswahl, Suspend-Timing, Resume-Signaling, Endpoint-Recovery und ob der Host resumed oder re-enumeriert hat.

Bus Scope macht diese Evidence sichtbar, sodass "USB wake not working" eine konkrete Diagnose wird statt einer Treiber-Schuld-Loop.