2026-06-02

USB Selective Suspend Debugging: Random Disconnects, Sleep Resume Failures, and Missing Transfers

How USB selective suspend can cause random device disconnects, missing transfers, resume failures, and idle-time bugs, and how to diagnose it with USB evidence.

USB selective suspend is supposed to save power. When it works, idle devices enter a low-power state and resume when needed. When it fails, users see random disconnects, missing data, frozen cameras, serial ports that stop responding, HID devices that miss input, or devices that disappear after sleep. Searches like "USB selective suspend random disconnect", "USB device stops working after idle", "USB resume failure", and "disable USB selective suspend" usually come from people who have already tried cables and drivers.

Disabling selective suspend can be a workaround, but it is not a diagnosis. The real question is whether the device, driver, hub, host controller, or application fails during suspend/resume or idle-time recovery.

Bus Scope helps because the failure has a timeline. You need to know what traffic occurred before idle, whether the host suspended the path, what request resumed the device, and which transfer failed after resume.

Direct answer: reproduce from a known working state, preserve the complete idle interval, and identify the first transfer or reset after idle. Compare the same operation with autosuspend/selective suspend enabled and disabled, then with a direct port and the reported hub. A workaround that disables suspend is useful evidence, but the fix belongs to the first resume, endpoint-restoration, policy, or topology step that diverges.

What selective suspend does

Selective suspend allows the operating system to suspend an individual USB device or interface while the rest of the system remains active. This is different from full system sleep. A USB device can be suspended because it appears idle even while the computer is otherwise awake.

This matters for:

USB serial adapters
HID devices
USB cameras
Audio interfaces
Debug probes
Security tokens
Custom vendor devices
Bus-powered sensors

If the device firmware does not handle suspend/resume correctly, the first transfer after idle may fail.

Typical symptoms

Selective suspend issues often look like:

Device works after plug-in but fails after a few minutes.
First command after idle times out.
Serial read blocks forever after inactivity.
Camera preview freezes after screen lock.
HID reports stop until unplug/replug.
Device reconnects with a new address.
Application says device disconnected even though it is still physically attached.
Windows or Linux logs show reset or resume-related messages.

The key pattern is time. If the failure follows idle periods, sleep/resume, display off, or laptop power state changes, power management belongs in the investigation.

Suspend failure vs resume failure

There are two different problems:

Suspend failure: the device or driver cannot enter low power correctly.
Resume failure: the device enters low power but does not return correctly.

From the user perspective both may look like "device disconnected." The USB trace can separate them by showing whether traffic stopped cleanly and whether the next request after idle failed.

If the device disappears only after the application sends a command after idle, suspect resume or firmware state restoration. If the device resets while idle with no application request, suspect host power management, hub behavior, or device firmware watchdog behavior.

First transfer after idle

The first transfer after idle is often the most important evidence. It may be:

A control request.
A bulk read or write.
An interrupt IN poll.
A class-specific request.
A vendor command.
A stream restart request.

If the first transfer times out, stalls, or triggers reset, the device likely did not resume into the expected state. The fix may be firmware resume handling, driver power policy, application retry behavior, or disabling selective suspend for that device.

Build a transition table:

Phase	Evidence	Result
active	known command and response	succeeds
idle	last transfer and time gap	path suspends
resume trigger	class, bulk, or interrupt request	submitted
first completion	data, STALL, timeout, or reset	classify
recovery	retry, clear halt, or re-enumeration	succeeds/fails

The first failed row is the diagnosis anchor. Later "device removed" notifications are consequences.

Runtime power management on Linux

Linux also has USB runtime power management. Devices can autosuspend after an idle delay. A device may behave differently depending on driver, kernel version, autosuspend settings, and whether an application keeps the device open.

For Linux investigations, capture the traffic and correlate with system logs. If the device resumes and immediately resets, the bus trace is more useful than a generic "I/O error" from the application.

Windows selective suspend

On Windows, selective suspend behavior depends on power plan, driver support, USB hub settings, and device class. Users often disable "USB selective suspend setting" in power options. That can be a practical workaround, but a professional diagnosis should still explain whether the device failed during idle recovery.

Windows USB issues can also be affected by Modern Standby, laptop dock behavior, hubs, and host controller drivers. A device may work on a desktop but fail on a laptop dock because suspend and resume behavior differs.

Do not confuse remote wake with ordinary resume

A device may resume because the host starts traffic, or it may request host wake after an external event when remote wake is enabled. These are different tests.

For an idle command failure, inspect host-initiated resume and the first command. For a keyboard or button that should wake the system, verify capability, host feature enablement, and device signaling. The remote-wakeup guide covers that permission chain.

Endpoint restoration after resume

Firmware can restore clocks but forget one data path:

bulk OUT buffer is not armed;
interrupt IN report queue is stale;
selected alternate setting is not reflected internally;
class protocol mode returns to default;
a previously halted endpoint stays halted;
application session state is lost.

Test each relevant endpoint's first transfer after idle. A composite device can resume HID while CDC remains silent, so report by interface rather than only parent device.

Use disablement as an A/B test

Compare:

Test	Suspend policy	Same idle time	Result
A	enabled	5 min	first bulk IN times out
B	disabled	5 min	command succeeds
C	enabled, direct port	5 min	command succeeds

This narrows the failure to power-state/topology interaction. It does not by itself prove whether firmware, hub, controller, or OS policy is wrong. Preserve both captures and host power logs.

Preserve application-handle behavior

After a failed resume, determine whether the USB device continued under the same configured session or re-enumerated. If descriptors and a new address appear, the application must treat the old handle as invalid. Repeatedly retrying the original handle can create a long series of user-space timeouts after the bus has already established a new device instance.

Record the application's reopen policy, device-selection key, and delay. If it matches by serial, verify the serial remains stable. If no serial exists, topology-based matching may change when a dock or hub reconnects. This host recovery question is separate from the firmware defect that triggered re-enumeration.

Capture strategy

To capture a selective suspend bug:

Start capture while the device is working.
Perform a known successful operation.
Let the device sit idle long enough to trigger the issue.
Perform the operation that usually fails.
Continue capture through timeout, reset, or reconnect.
Save the full timing window.

Do not start the capture only after the device has already failed. You need the transition from active to idle to failure.

What to look for

In the trace, inspect:

Last transfer before idle.
Time gap before failure.
First transfer after idle.
Timeout, stall, reset, or disconnect.
Re-enumeration after failure.
Change in device address.
Class-specific request after resume.
Endpoint halt recovery.
Alternate setting changes for streaming devices.

Timing is not noise here. Timing is the evidence.

Debug checklist

Use this order:

Confirm whether failures correlate with idle time.
Test on AC power and battery power.
Test direct port vs hub or dock.
Capture before idle and through failure.
Identify the first failed transfer after idle.
Check whether the device resets or only a transfer fails.
Compare with selective suspend disabled.
Compare another OS or host controller.
Check firmware resume handling.
Check driver power policy and application retry behavior.
Test first post-idle transfer on each interface.
Distinguish normal resume from reset and re-enumeration.

QA questions

Is disabling USB selective suspend a complete fix?

It can be a practical workaround and a useful A/B test. It does not identify the failed suspend/resume step or prove firmware and driver power behavior are correct.

Why does the application report disconnect when the cable stayed attached?

The host may reset and re-enumerate the device after resume failure, invalidating the old handle. Trace descriptors and address assignment after the idle gap.

Can only one function of a composite device fail after idle?

Yes. Endpoint queues and class state can be restored per interface. Test the first transfer on each function.

Can Bus Scope prove a platform power-policy bug?

It can show USB traffic, timing, resets, and endpoint behavior. OS power tracing is needed when policy decisions occur above the bus.

Final diagnosis

USB selective suspend problems are not solved well by guessing. Disabling power management may reduce symptoms, but the real engineering answer comes from the USB timeline: active traffic, idle gap, resume attempt, failed transfer, reset, or recovery.

Bus Scope helps preserve and inspect that evidence so a "random USB disconnect" can be diagnosed as a specific suspend/resume, driver, firmware, hub, or power-management failure.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: