USB Remote Wakeup and Suspend Resume Debugging: Selective Suspend, Resume Signaling, Power Management, and Missed Wake Events

USB power management bugs are hard to diagnose because the device may work perfectly while the system is active and fail only after idle, sleep, selective suspend, dock sleep, laptop lid close, or monitor power-off. Users search for "USB remote wakeup not working", "USB selective suspend disconnect", "USB device does not wake computer", "USB resume failure", "USB suspend resume bug", and "HID keyboard wake from sleep not working".

BusScope is useful because suspend and resume are bus-level events, not only application errors. You need to see whether the host suspended the device, whether remote wakeup was enabled, whether the device signaled resume, whether the host resumed traffic, and whether the device re-enumerated instead of resuming.

What remote wakeup means

Remote wakeup allows a suspended USB device to request that the host resume communication. Common examples include:

• Keyboard wakes a sleeping desktop.
• Mouse wakes a laptop from idle.
• Dock button wakes a workstation.
• Barcode scanner wakes a kiosk.
• Industrial controller wakes a panel PC.
• HID sensor wakes a host after an external event.

Remote wakeup is not simply "the device has power". The host must allow it, the device must advertise support, the feature must be enabled, and resume signaling must occur at the right time.

Common symptoms

Remote wakeup and suspend issues look like:

• Device works until the PC sleeps.
• Device does not wake the computer.
• Device wakes the system immediately after suspend.
• Device disappears after resume.
• Device re-enumerates with a new address.
• HID input is missed after idle.
• Serial device stops sending after selective suspend.
• Audio or camera device returns from sleep with no data.
• Firmware only recovers after unplug/replug.

These symptoms are often blamed on drivers, but the capture may show a firmware power-state problem.

Descriptor and feature evidence

The configuration descriptor can advertise remote wakeup capability. The host can then enable or disable the remote wakeup feature. A useful USB diagnostic trace should answer:

• Does the device advertise remote wakeup?
• Did the host send SET_FEATURE(DEVICE_REMOTE_WAKEUP)?
• Did the host later clear the feature?
• Did suspend occur after idle?
• Did the device attempt resume signaling?
• Did the host resume normal transfers?

Without these facts, the diagnosis is guesswork.

Selective suspend

Selective suspend lets the operating system suspend an idle USB device without putting the whole system to sleep. This saves power, but it exposes firmware bugs.

Failure patterns:

• Device enters low-power state but does not restore endpoint state.
• Firmware loses pending interrupt IN state.
• Device NAKs forever after resume.
• Host resets the device after timeout.
• Application sees timeout or device removal.
• Composite device resumes one interface but not another.

Searchers often type "USB selective suspend random disconnect" because the device appears to disconnect even though the real event is suspend/resume failure.

Resume vs re-enumeration

After sleep, there are two very different outcomes:

• Resume: same device continues with existing configuration.
• Re-enumeration: host resets and enumerates the device again.

Re-enumeration may be acceptable after physical disconnect, but it is suspicious after normal suspend. It can break applications that hold open handles, serial port names, HID paths, or camera capture sessions.

BusScope should help identify whether the trace contains normal resume traffic or a new enumeration sequence with GET_DESCRIPTOR, SET_ADDRESS, and SET_CONFIGURATION.

Missed wake events

Sometimes the device sees the external event but the host does not wake. Causes include:

• Remote wakeup not advertised.
• Remote wakeup not enabled by host.
• Device sends resume too early.
• Device sends resume too late.
• Hub blocks or mishandles wake signaling.
• BIOS or OS wake policy disables the port.
• Device firmware enters a deeper sleep than expected.
• The event occurs before suspend is complete.

Packet-level evidence does not replace OS power policy, but it narrows the question. Did the device have permission to wake the host, and did it attempt to do so?

Immediate wake after suspend

The opposite problem is also common: the system suspends and immediately wakes again. USB devices can cause this when they signal wake due to stale input, noisy interrupt state, debounce bugs, or firmware that treats suspend as a new event.

Evidence to collect:

• Last interrupt report before suspend.
• Whether the host enabled wake.
• Timing between suspend and resume.
• Device class and interface.
• Whether the same endpoint had pending data.
• Whether the event repeats on every suspend attempt.

This is especially common with keyboards, mice, touch panels, game controllers, and custom HID devices.

Debug checklist

Use this process:

1. Capture enumeration from plug-in.
2. Confirm remote wakeup capability in descriptors.
3. Check whether host enables remote wakeup.
4. Record the idle period before suspend.
5. Identify suspend timing.
6. Look for resume signaling or host resume traffic.
7. Separate resume from full re-enumeration.
8. Check endpoint behavior after resume.
9. Compare the same device on a direct port and through a hub.
10. Preserve both pre-suspend and post-resume packets.

Final diagnosis

USB remote wakeup and suspend/resume bugs are power-state protocol problems. The useful evidence is descriptor capability, host feature selection, suspend timing, resume signaling, endpoint recovery, and whether the host resumed or re-enumerated the device.

BusScope helps make that evidence visible so "USB wake not working" becomes a concrete diagnosis instead of a driver blame loop.