Re: correctly handling EPROTO

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

[-- Attachment #1: Type: text/plain, Size: 5448 bytes --]

On Mon, Mar 23, 2026, Oliver Neukum wrote:
> 
> 
> On 21.03.26 03:14, Thinh Nguyen wrote:
> > On Fri, Mar 20, 2026, Alan Stern wrote:
> > > On Thu, Mar 19, 2026 at 11:16:22PM +0000, Thinh Nguyen wrote:
> > > > On Wed, Mar 18, 2026, Alan Stern wrote:
> 
> > > Naturally, UAS may be a totally different situation.
> > 
> > Windows has a clever way to handle this for UAS. It sends a command/task
> > with the same tag as the failing transfer on the command endpoint,
> > triggering an overlap tag response and causing the device side to cancel
> > the command along with the pending data transfer. This puts the host and
> > device in sync again.
> > 
> > All compliant UAS devices must support overlap tag detection.
> > 
> > (We can go into more detail should we want to pursue this)
> 
> _yes_
> 
> Do you have a trace?
> 

I attached a couple of usb traffic sniffing traces. Review comments
below.

<snip>

> > 
> > The clear-halt doesn't have to be done after the unlinking of URBs. The
> > xhci endpoint is in stopped state after a reset ep command. As
> > long as the class driver doesn't submit a new URB to trigger a doorbell
> > ring, the xhci driver can send a clear-halt after a reset ep command and
> > no transfer will start.
> 
> How do we tell drivers about that? If we give back the URB it must
> be unlinked.
> 

Yes it must. I was responding to Alan's comment that noting that it can
be done prior or after unlinking the URBs. But as Michal noted, that may
not be possible because we ring the doorbell right after giving back an
URB.

---

Now, about the attached traces. They were captured some ~3 years ago on
certain build of Windows 10. One trace shows transaction error response
to data IN endpoint, the other trace shows transaction error response to
data OUT endpoint. These are some off-the-shelf devices tested behind a
hub.

win10_uasp_clear_halt_ep1in_T7.txt:
-----------------------------------
Unfortunately, this test was run with a single tag number, so it's not a
very good demonstration of the recovery. However, you can see
transaction error to this SCSI READ(10) and stopped at 146432 bytes:

	_______|_______________________________________________________________________
	SCSI Op(85) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x0928FC00) Data(146432 bytes) Status(Missing)-BAD 
	_______| Time(  2.681 ms) Time Stamp(10 . 006 968 662) Metrics #Xfers(2) 
	_______|_______________________________________________________________________

Then clear-halt and host sends a new command with the same tag, causing
an overlapped response:

	Transfer(289) Left("Left") G2(x1) Control(SET) ADDR(3) ENDP(0) 
	_______| bRequest(CLEAR_FEATURE) wValue(ENDPOINT_HALT) wLength(0) 
	_______| Time(166.322 us) Time Stamp(10 . 009 649 516) 
	_______|_______________________________________________________________________
	SCSI Op(99) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x09290000) RESPONSE_CODE(OVERLAPPED TAG) 
	_______| Time(365.854 us) Time Stamp(10 . 009 815 838) Metrics #Xfers(2) 
	_______|_______________________________________________________________________

Then the host retry starting from where the failing SCSI command was:

	SCSI Op(100) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x09290400) STATUS(GOOD) Data(524288 bytes) 
	_______| Time(  1.012 sec) Time Stamp(10 . 010 181 692) Metrics #Xfers(3) 
	_______|_______________________________________________________________________
	SCSI Op(101) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x0928FC00) STATUS(GOOD) Data(524288 bytes) 
	_______| Time(882.412 us) Time Stamp(11 . 022 469 104) Metrics #Xfers(3) 
	_______|_______________________________________________________________________
	SCSI Op(102) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x09290000) STATUS(GOOD) Data(524288 bytes) 
	_______| Time(  1.060 ms) Time Stamp(11 . 023 351 516) Metrics #Xfers(3) 
	_______|_______________________________________________________________________
	SCSI Op(103) ADDR(3) Tag(0x0002) SCSI CDB READ(10) 
	_______| Logical Block Addr(0x09290800) STATUS(GOOD) Data(524288 bytes) 
	_______| Time(  1.013 ms) Time Stamp(11 . 024 411 510) Metrics #Xfers(3) 
	_______|_______________________________________________________________________

And recovery was successful and transfers resumed.

win10_uasp_clear_halt_ep1out_T7.txt:
-----------------------------------
This file is viewed at the Transfer level because it's difficult to see
at SCSI Op level. This one has multiple transaction errors and triggers
multiple clear-halts from host. After the host retries a few times to
the same transfer, it gave up retrying. The last thing you see in that
trace is the host performing clear-halt due to transaction error:

	_______|_______________________________________________________________________
	Transfer(293) Left("Left") G2(x1) Control(SET) ADDR(4) ENDP(0) Route String(3) 
	_______| bRequest(CLEAR_FEATURE) wValue(ENDPOINT_HALT) wLength(0) 
	_______| Time Stamp(21 . 540 631 880) 
	_______|_______________________________________________________________________

After a certain amount of time, from what I recall, the host will
perform port reset recovery due to transfer timeout similar to Linux.

BR,
Thinh

[-- Attachment #2: uas_clear_halt.tar.gz --]
[-- Type: application/x-tar-gz, Size: 2242 bytes --]