Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd

[Vladimir Nikishkin <lockywolf@gmail.com>]

Vladimir Nikishkin <lockywolf@gmail.com> writes:

I seem to be having a problem similar to the one Sedat Dilek had.
My usb 3.0 'ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E
SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s
bridge' is getting reset under load.
I tried adding the 't' flag, but the drives is still getting reset with
the following message in dmesg:
```
[  +0.004767] scsi host6: uas_eh_device_reset_handler start
[  +0.066198] usb 2-2.4.2: reset SuperSpeed USB device number 91 using xhci_hcd
[  +0.014680] scsi host6: uas_eh_device_reset_handler success
[Mar29 23:01] sd 6:0:0:0: [sde] tag#18 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 
[  +0.000007] sd 6:0:0:0: [sde] tag#18 CDB: opcode=0x8a 8a 00 00 00 00 01 97 1d e4 08 00 00 04 00 00 00
[  +0.000042] sd 6:0:0:0: [sde] tag#17 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 
[  +0.000004] sd 6:0:0:0: [sde] tag#17 CDB: opcode=0x8a 8a 00 00 00 00 01 97 1d e0 08 00 00 04 00 00 00
[  +0.000071] sd 6:0:0:0: [sde] tag#16 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT 
[  +0.000004] sd 6:0:0:0: [sde] tag#16 CDB: opcode=0x8a 8a 00 00 00 00 01 97 1d e0 00 00 00 00 08 00 00
[  +0.000027] sd 6:0:0:0: [sde] tag#15 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT 
[  +0.000004] sd 6:0:0:0: [sde] tag#15 CDB: opcode=0x8a 8a 00 00 00 00 01 97 1d dc 00 00 00 04 00 00 00
[  +0.005166] scsi host6: uas_eh_device_reset_handler start
[  +0.065988] usb 2-2.4.2: reset SuperSpeed USB device number 91 using xhci_hcd
[  +0.014673] scsi host6: uas_eh_device_reset_handler success
```

I have also captured the usbmon log. The file is too big for an email
attachment, so I uploaded it to my server.
http://public.lockywolf.net/pub/usbmon-dump.bus2-without-smart-udisks.txt.gz


I have seen reports that firmware needs to be updated in those chips in
order to support large drives
(https://www.computerbase.de/forum/threads/asmedia-aktuelle-externe-gehaeuse-chip-firmware-fuer-8tb.1473501/page-2
and also
https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/
)
Googling for ASM1153+Raspberryp Pi returns quite a lot of difficulties
with using those chips. (Although I am not using it with Raspberry Pi)
(https://github.com/raspberrypi/linux/issues/3070
https://bugzilla.redhat.com/show_bug.cgi?id=1230336
https://community.home-assistant.io/t/usb-boot-on-raspberry-pi-4/172223/61
https://blog.franco.net.eu.org/notes/a-solution-to-io-errors-on-usb3-external-hdd-enclosures.html)


Maybe it is not on only the ATA command that is leading to a reset?
In my case the device is getting reset after ~30 Gb transferred via
rsync.

Disabling uas makes the issue a little less likely to get hit, in the
sense that even though resets happen, they do not interrupt a transfer,
but in fact the issue still remains: after ~50 "minor resets", the
device get reset in some other fundamental way, so that /dev/sdX
numbering changes.

Any debugging suggestions welcome. (I will try to rebuild the kernel
with the sysctl debug patch.)


-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)