Dennis HilkLinux Fix LabDE

Storage & Filesystems

USB storage resets while using UAS

Investigate USB mass-storage aborts by separating cable and power faults from bridge-specific UAS behavior, with a narrowly scoped fallback comparison.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • An external drive stalls, resets or disappears during copies.
  • The log names uas_eh_abort_handler or a failed UAS reset.

Relevant environment

USB SATA/NVMe bridges bound to the uas driver; devices using usb-storage already need different checks.

Recognizable messages (synthetic examples)
sd 6:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT

Check the preceding USB/storage failure; this is not proof that UAS rather than the cable caused it.

sd 6:0:0:0: uas_eh_device_reset_handler FAILED

Repeated recovery failure warrants data preservation and physical path checks before transport tuning.

Possible causes

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

  • Cable signal quality, bus power, hub problems or controller faults can break USB I/O.
  • A bridge firmware defect can affect UAS command handling; a USB transport fallback is evidence only when compared under the same conditions.

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 the USB tree, negotiated speed and driver binding without changing the bus.

lsusb -t

Interpret the result: Driver=uas confirms this entry applies. Shared hubs and speed changes provide leads but do not identify a defective cable alone.

Check 2

Read USB, UAS, SCSI and filesystem events in order; journal privileges may be required.

journalctl -k -b --no-pager -n 350

Interpret the result: An abort is error recovery after a stalled command; failed reset escalates the concern. USB disconnects can also be intentional, so compare the workload timing.

Evidence-guided next steps

Compare a direct USB connection

If failures occur through a hub or questionable cable, stop access, unmount safely and compare a known-good short cable on a direct port. For power-dependent devices use the specified power supply or a suitable powered hub.

Precautions: Do not unplug during writes. Secure data before repeated tests because resets can leave a filesystem inconsistent.

Recovery / rollback: Safely unmount and restore the recorded connection if the alternative path is worse.

Did this solution help you?

Share this solution#

Compare a device-specific UAS fallback

If the physical USB path is stable but UAS aborts persist, identify the bridge VID:PID with lsusb and test usb-storage.quirks=VID:PID:u for one boot. This binds that matching bridge to the older bulk-only storage transport.

Precautions: Replace VID:PID with four-digit hexadecimal IDs; do not copy another enclosure’s IDs. Throughput and command queueing can worsen, and root-on-USB systems need a recovery boot.

Recovery / rollback: Boot without the quirk and verify Driver=uas returns. Keep any permanent quirk limited to hardware confirmed affected.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.

Related hardware and driver context

These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.

Identify hardware locally