2026-06-02

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

Fix USB UASP protocol failures and BOT fallback issues. Diagnose mass storage reset loops, SCSI command timeouts, slow external drives, enclosure firmware bugs, and UASP vs BOT transfer speed differences.

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:

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

Turn the trace into a transport decision

The useful outcome is not a long list of USB frames. It is a small claim that another engineer can test: the host was still issuing a particular SCSI command, the bridge stopped completing its USB transport, and the operating system reset the device after a defined timeout. Start by marking one workload boundary, such as the first sustained write, then read outward until the first abnormal event. Do not begin at the final disconnect; that event is often the host's recovery, not the original failure.

Observation in the capture	Strongest working explanation	Next comparison
BOT CBW arrives but the matching CSW never arrives	The bridge, cable, power path, or device stopped completing the command	Repeat on a direct port with the same workload
UASP commands queue, then several time out together	A bridge/driver queue or task-management recovery is involved	Compare the same disk in BOT mode or another enclosure
A reset follows one opcode every time	The failing operation is more specific than generic throughput	Record the opcode, transfer direction, length, and preceding command
Reset happens only through a hub or long cable	Power or signal integrity is a credible variable	Preserve the topology and repeat direct-to-host
The drive disappears before the host issues recovery traffic	Device or bridge firmware may be resetting autonomously	Correlate USB disconnect timing with enclosure LEDs, power, and firmware logs

For BOT, the sequence should be read as a transaction: one CBW identifies the command, the data phase proves how much transferred, and the CSW closes the operation. A missing CSW matters only after confirming that the capture began before the CBW and that the endpoint direction is correct. A zero-length or short data phase can be legitimate for some SCSI commands; it becomes evidence of failure when it disagrees with the requested length, residue, status, and the host's immediate recovery. Keep STALL clearing and the Bulk-Only Mass Storage Reset in the same evidence window because they explain why the host changed state.

For UASP, avoid treating concurrency as corruption. Multiple commands may be outstanding, so a timeout seen near an unrelated command does not prove that command caused the reset. Build a short timeline with command identifier, arrival order, completion or status, and task-management activity. If all outstanding commands fail only after one bridge response disappears, the first gap is more informative than the final group of errors. This is also why a single screenshot is weak handoff evidence: it hides the ordered relationship between the command, timeout, abort, reset, and re-enumeration.

Questions to answer before replacing hardware

Does BOT working prove that the disk is healthy? No. It proves that one transport path survived the tested workload. It makes the UASP driver, bridge firmware, command queueing, cable, power budget, and host controller more useful places to investigate, while leaving the disk itself open as a separate possibility.

Does a USB reset prove a cable fault? No. A reset is a recovery action. Compare topology, workload, transport mode, and the last completed command before naming the cable. A cable or power path becomes a stronger explanation when the failure moves with it and disappears on a direct short connection.

What should a vendor receive? Include the capture start condition, device and enclosure identity, host OS/controller, BOT or UASP mode, exact workload, first abnormal command, recovery sequence, and the result of one controlled comparison. The Bus Scope troubleshooting guide and platform capture setup explain how to preserve that packet context without reducing the case to an unsearchable log.

A controlled test matrix beats one long copy operation

Use the same source data, drive, enclosure, and destination filesystem for a small matrix. Change one variable at a time: direct port versus hub, short cable versus installed cable, UASP versus BOT fallback, and host A versus host B. Record whether the first abnormal command, timeout duration, and reset behavior move with the variable. A result such as “fails only with this enclosure under UASP on two hosts, while the same drive succeeds in another enclosure” is much more actionable than “disk unstable.” Conversely, if every topology fails on the same SCSI operation, preserve the command evidence before blaming USB transport alone.

Do not turn a fallback into a permanent conclusion too early. BOT can be a useful containment path, but it changes queueing and error recovery as well as throughput. Note the performance cost, the workload that triggers failure, and whether the bridge firmware version changed. If an OS driver silently falls back after an error, capture both the pre-fallback UASP session and the later BOT session so the comparison is based on packets rather than a device-manager label.

Finally, say what the trace cannot prove. USB traffic can show a missing completion, a reset, and repeatability at the host interface. It cannot by itself prove NAND wear, a spinning-disk mechanical fault, or a power-supply ripple inside an enclosure. That boundary keeps the report credible while still giving hardware, firmware, and support teams a precise next experiment.

Before closing the case, compare the captured reset interval with the operating system event time, but keep the two sources labeled separately. The host event log records what the driver decided; the USB trace records transport events visible before that decision. If the times disagree, investigate timestamp bases and capture placement before treating the difference as a device delay. This discipline prevents a useful trace from being weakened by an overconfident claim.

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.

Storage timeout QA questions

Treat a reset loop as a sequence, not a single storage error. Preserve the final successful command, the first command that fails to complete, the observed timeout window, any recovery/reset activity, and the first command after recovery. Repeat the same bounded workload after one controlled variable changes.

Test	What it separates
Small read and write	Basic transport viability from sustained-load failure
Large sequential workload	Queueing, cache flush, or bridge recovery behavior
Direct port versus hub	Topology correlation without claiming electrical proof
Same drive in another enclosure	Drive media question from bridge/transport question
UASP session versus BOT fallback	Transport semantics from filesystem-level symptom

If a BOT fallback is stable, record it as containment rather than proof that UASP is defective. The two transports differ in queueing and recovery, so the comparison must retain command ordering and reset evidence. A host-visible trace can show the sequence observed at that host; it cannot independently prove drive mechanics, enclosure power quality, or a cable’s physical integrity.

Is a reset after a SCSI error always an enclosure firmware bug?

No. The trace can establish ordering—command, status absence or error, recovery, reset—but not the component that made recovery necessary. Compare another host, port, enclosure, and controlled workload before assigning ownership. Keep the first abnormal command and timing window with the report.

What is the safest first mitigation?

Reduce the reproduction to a bounded workload and preserve the UASP trace before changing drivers, cables, or fallback policy. A reversible BOT fallback can help restore access, but retain the original UASP evidence so later firmware or hardware analysis has a baseline.

Practical questions

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: