Re: Inquiry about the f_tcm: Enhance UASP driver work

["Michał Pecio" <michal.pecio@gmail.com>]

Hi,

> > I tried to use it on dwc3, though I fix some other problems, the host side xhci
> > (ubuntu client) using fio for stress testing, and I encountered the following
> > error on host:
> > [18836.092159] xhci_hcd 0000:00:0d.0: Transfer error for slot 3 ep 1 on
> > endpoint
> > [18836.092211] sd 0:0:0:0: [sda] tag#11 data cmplt err -71 uas-tag 1 inflight:
> > CMD
> > [18836.092213] sd 0:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 02 5e 31 00 00 01
> > 00 00
> > .....more and mores....
> > [18867.369118] scsi host0: uas_eh_device_reset_handler start [18867.453796] usb
> > 2-3.2: reset SuperSpeed USB device number 4 using xhci_hcd
> > and the gadget side is keep resetting configfs and printing wait_for_completion
> > timeout (since dwc3 have )
> > 
> > I am not sure whether this is due to the stream exception of dwc3 or some
> > logical in f_tcm and target.
> 
> The error is -71. This is transaction error (could be a CRC error). It
> could be due to the host, device hardware, electrical interference, or
> even the cable. No logical issue from software.

A transaction error is a transaction error, but waiting 30 seconds for
UAS to reset the device afterwards looks wrong. I seem to recall seeing
sporadic transaction errors which triggered the reset instantly.

Long delays I have seen mainly on some unfortunate pairings of HC and
device (HW bugs?) which trigger unusual error conditions poorly handled
by xhci_hcd. Try with dynamic debug on handle_transferless_tx_event(),
if your kernel is recent enough for that to be a separate function.

In those cases, UAS seems to wait for other streams to complete before
resetting, but the whole endpoint is stopped and nothing moves forward.
At least that's the impression I got, I was looking at other things.

If you aren't running into this case, I would say something may be wrong
with UAS implementation on one or the other side.

It looks like the transaction error was delivered to UAS by means of
-EPROTO status so xhci_hcd has done its job at least for this one URB.
No idea what happened later and why the device wasn't reset promptly.

Regards,
Michal