What does a failing USB-to-SATA bridge look like in the kernel log, and how do you tell it from a failing disk?

The answer. When a USB-attached disk shows repeating abort lines followed by a SuperSpeed USB reset, the sources opened here treat it as a host-to-bridge fault first. The reason is in the driver: the comment above uas_eh_abort_handler in uas.c says the driver does not support actually sending an abort to the device, so the handler always fails, and the next escalation in the same file resets the whole USB device (usb_reset_device) and fails every pending command with DID_RESET. A reset of that kind says nothing about whether the disk has bad sectors.

What the numbers show. In the one fully quoted case (2015, ASMedia 174c:55aa), the first read error was at 7505.098 s and the abort at 7535.253 s, 30.2 s later (derived). The 2024 LaCie excerpt shows the same shape: a Mode Sense(6) command aborted at 87.366 s, a reset that finished 0.17 s later (derived), and another reset starting at 118.103 s, about 30.6 s after that (derived). Two intervals near 30 s in two unrelated devices fit a fixed command timeout, but the sources do not state the timeout value, so this page does not assert one.

Why the disk is not automatically the suspect. After the 2015 reset the bridge returned Not Ready, Medium not present for a disk that was still attached and, after UAS was disabled, read its entire 1.5 TB at about 125 MB/s. The same drive therefore passed a full-surface read behind the same bridge under a different driver. That is one drive, one pass, one poster; it shows the bridge or the UAS path can fail without the disk, not that the disk is healthy.

What the workaround does and does not fix. Disabling UAS per VID:PID (quirk letter u) is the remedy in the kernel table (8 of 24 entries), in the Launchpad bug and in the 2024 patch, but it is not a cure: the 2015 poster still logged 953 resets, a Launchpad commenter reported resets continued, and the Launchpad thread also records commenters for whom a different kernel or a different host made the problem disappear. A quirk list also cannot identify the bridge chip: in 2015 the enclosure reported ASM1051 to lsusb while the poster says the board carried an ASM1153E, and the kernel's unusual_devs.h entry for the same 174c:55aa ID applies only to bcdDevice 0x0100 and names an AS2105.

What SMART can and cannot say through a bridge. smartctl needs a bridge-specific pass-through for several chips and warns that a wrong choice causes I/O errors and may disconnect the drive, so a failed SMART query over USB is a statement about the bridge until a direct SATA connection says otherwise. When the bridge swallows SMART RETURN STATUS, smartctl falls back to comparing pre-failure attribute values with thresholds, which is a weaker test than the drive's own verdict. Read the drive's attributes directly where possible, and compare them with the SMART, SCSI sense and SATA/SAS link notes before concluding anything about the disk.