USB UASP Protocol vs BOT: Fix Mass Storage Reset Loops, Timeouts, and Slow Transfer Speeds

An external disk that mounts normally but stalls under load, falls into a USB mass-storage reset loop, or becomes fast only after UASP is disabled may have a transport problem rather than a filesystem problem. Compare UASP commands and status with BOT CBW/CSW exchanges, SCSI failures, resets, and the exact I/O that preceded the timeout. This evidence can distinguish a USB UASP timeout, BOT framing error, or bridge reset; it cannot establish platter, flash, cable, or power health without additional tests.

Bus Scope is useful because USB storage is not just filesystem I/O. Below the file copy dialog, the host sends SCSI commands over USB transports.

BOT and UASP

USB Mass Storage Bulk-Only Transport, or BOT, is older and widely supported. It uses command block wrappers, data transfers, and command status wrappers.

UASP, USB Attached SCSI Protocol, is newer and supports more efficient command queuing over USB. It can improve performance, but it also depends on bridge firmware, host controller behavior, driver support, and cable quality.

Symptoms can differ:

• BOT works but is slow.
• UASP is fast until it resets.
• UASP fails on one machine but BOT works on another.
• External enclosure resets under heavy writes.
• Drive disappears during large transfers.

Reset loops under load

If a drive enumerates and mounts but resets during writes, look around the first failing workload:

• Large sequential write.
• Random I/O burst.
• SMART query.
• Cache flush.
• SCSI reset.
• USB bulk timeout.
• Device disconnect.

The visible OS error may be "I/O error", "device not ready", or "disk removed." The bus trace can show whether the USB bridge stopped responding or the host reset it.

BOT evidence

For BOT, inspect:

• Command Block Wrapper
• Data phase
• Command Status Wrapper
• SCSI command opcode
• Transfer residue
• STALL recovery
• Bulk-only mass storage reset

If the CSW is missing or invalid, the host may reset the device.

UASP evidence

UASP uses streams and SCSI task management. Failures may appear as command timeouts, aborted tasks, or resets. UASP traces can be more complex than BOT, but the core question is still: which command was in flight when the device stopped responding?

Bridge firmware bugs are common in focused enclosures. Testing the same disk in another enclosure can separate disk health from USB bridge behavior.

Power and cable

Storage devices draw real power, especially spinning disks and high-performance SSDs. A marginal cable or bus-powered hub can produce resets only under write load.

If resets correlate with heavy I/O, test:

• Short cable.
• Direct port.
• Powered hub.
• Another enclosure.
• Another host controller.

Keep the capture; topology tests are stronger when paired with packet evidence.

Debug checklist

Use this workflow:

1. Capture enumeration and identify BOT or UASP.
2. Capture mount and first heavy I/O.
3. Identify last successful SCSI command.
4. Look for bulk timeout, STALL, reset, or disconnect.
5. For BOT, inspect CBW and CSW.
6. For UASP, inspect command/task behavior.
7. Compare direct port vs hub.
8. Compare UASP and BOT fallback if possible.
9. Test another enclosure with the same drive.
10. Preserve timing around the first reset.

Final diagnosis

USB mass storage failures are often transport and bridge problems, not just disk problems. UASP, BOT, SCSI commands, bridge firmware, power, cable, and host controller behavior all matter.

Bus Scope helps expose the USB storage conversation so reset loops and slow-drive symptoms can be traced to real bus-level evidence.