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.