USB device disappears after idle or resume · Linux Fix Lab

Symptoms & scope

A connected USB mouse, keyboard, camera or gamepad disappears after inactivity or a suspend/resume cycle.
The kernel journal logs a USB disconnect/reconnect, failed reset or descriptor read error near the user's observed failure.

Relevant environment

USB HID devices, webcams, controllers and other peripherals on Linux systems with runtime USB power management; do not apply storage-specific UAS assumptions to every USB class.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

A device or driver may handle autosuspend or autoresume incorrectly, particularly when remote wakeup behaves differently from expectations.
A marginal cable, hub, port power or failing peripheral may produce the same disconnect messages independently of autosuspend. An event after resume does not uniquely identify energy management.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read connected USB devices and interface drivers before and after the failure.

lsusb -t

Interpret the result: A device missing after failure must first be identified by physical connection, bus and interface rather than a guessed sysfs number.

Check 2

Read USB/xHCI messages from the current boot; correlate their timestamps with the actual disconnect.

journalctl -k -b --no-pager --grep='usb|xhci|reset'

Interpret the result: USB reset or descriptor errors alone cannot distinguish a defective cable from a resume bug.

Check 3

Example sysfs path only. Replace 1-2 with the confirmed USB device path; do not assume this bus address exists.

cat /sys/bus/usb/devices/1-2/power/control

Interpret the result: auto permits runtime autosuspend; on prevents it for this device. Neither state proves that a suspend occurred.

Evidence-guided next steps

Check a direct connection before changing power policy

Record whether the same peripheral fails through a hub and on a direct known-good port or cable, without changing the driver or system power profile. Check power and data cables where removable. Compare kernel messages, device ID and time-to-failure. If direct connection solves it, this narrows the transport path but cannot on its own prove that autosuspend never mattered.

Precautions: Do not repeatedly power-cycle a mounted USB storage device with outstanding writes; avoid losing access to critical input devices.

Recovery / rollback: Reconnect to the original port or hub if it was stable, keeping notes of both paths.

Did this solution help you?

Share this solution #

Compare a single device's runtime PM with a reversible setting

If event timing consistently follows autosuspend, an administrator can make one carefully scoped temporary test by setting that confirmed device's power/control to on, preserving its old value. The documented kernel interface accepts on and auto; this is a targeted hypothesis test, not a universal tuning recommendation. Do not change usbcore's global default and do not unbind a hub or critical device.

Precautions: This setting may increase power use and may be reset by replugging. Avoid changing a remote keyboard or storage controller without backup access.

Recovery / rollback: Restore the recorded power/control value (usually auto or on) for that exact device when the comparison is done.