Hi Christoph, Out of curiosity, what exact device is this? I have an multi-disk JMS567 based enclosure which reports the same IDs from lsusb, doesn't work with uas at all. According to the datasheet for JMS567 it should support UAS, but I've received conflicting information from the manufacturer of my enclosure stating JMS567 has issues with UAS when multiple disks are involved, but further details weren't provided. Cheers, Jack On 19/05/17 00:30, Christoph Gohle wrote: > Hi, > > I have seen several reports around the internet regarding failing io on USB-SATA bridges. However, these reports seem to be partially old and/or fixes proposed are implemented in my kernel but don’t fix things. Therefore I thought I report here again. If this is know/duplicate please apologise. > > I am running on ubuntu 16.04 LTS with kernel > > $ ~> uname -a > Linux gserv 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > I was also using the 4.4.0-75-generic version of the kernel before, with same results. I am having a JMS567 bridge with (currently) three disks attached. > > $ ~> lsusb > Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > … > > $ ~> ls -l /dev/disk/by-id/ > total 0 > … > lrwxrwxrwx 1 root root 9 May 18 00:20 usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0 -> ../../sdc > lrwxrwxrwx 1 root root 10 May 18 00:20 usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part1 -> ../../sdc1 > lrwxrwxrwx 1 root root 10 May 18 00:20 usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part9 -> ../../sdc9 > lrwxrwxrwx 1 root root 9 May 18 00:20 usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1 -> ../../sdd > lrwxrwxrwx 1 root root 10 May 18 00:20 usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1-part1 -> ../../sdd1 > lrwxrwxrwx 1 root root 9 May 18 00:20 usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2 -> ../../sde > lrwxrwxrwx 1 root root 10 May 18 00:20 usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part1 -> ../../sde1 > lrwxrwxrwx 1 root root 10 May 18 00:20 usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part9 -> ../../sde9 > … > > I am running a ZFS filesystem on those… (actually two pools…). The system seems to run fine as long as there is only reading going on or only writing to one disk (possibly from somewhere else)…. > > However once I start a copy operation (here data coming from one of the above devices and going to the two others (in a mirror configuration), I get frequent io errors from the kernel: > > May 17 22:53:13 gserv kernel: [ 474.505548] xhci_hcd 0000:00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring > May 17 22:53:13 gserv kernel: [ 474.505670] xhci_hcd 0000:00:14.0: @000000026e54c460 00000000 00000000 04000000 02088001 > May 17 22:53:43 gserv kernel: [ 504.804185] sd 2:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN > May 17 22:53:43 gserv kernel: [ 504.804192] sd 2:0:0:0: [sda] tag#5 CDB: Read(16) 88 00 00 00 00 00 74 e9 b3 48 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804252] sd 2:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN > May 17 22:53:43 gserv kernel: [ 504.804256] sd 2:0:0:0: [sda] tag#3 CDB: Read(16) 88 00 00 00 00 00 74 e9 b2 48 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804299] sd 2:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN > May 17 22:53:43 gserv kernel: [ 504.804303] sd 2:0:0:0: [sda] tag#1 CDB: Read(16) 88 00 00 00 00 00 74 e9 b1 48 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804383] sd 2:0:0:2: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT > May 17 22:53:43 gserv kernel: [ 504.804387] sd 2:0:0:2: [sdc] tag#7 CDB: Write(16) 8a 00 00 00 00 00 e8 23 79 10 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804419] sd 2:0:0:2: [sdc] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT > May 17 22:53:43 gserv kernel: [ 504.804422] sd 2:0:0:2: [sdc] tag#6 CDB: Write(16) 8a 00 00 00 00 00 e8 23 78 10 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804468] sd 2:0:0:2: [sdc] tag#0 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT > May 17 22:53:43 gserv kernel: [ 504.804472] sd 2:0:0:2: [sdc] tag#0 CDB: Write(16) 8a 00 00 00 00 00 e8 23 77 10 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804510] sd 2:0:0:2: [sdc] tag#2 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT > May 17 22:53:43 gserv kernel: [ 504.804514] sd 2:0:0:2: [sdc] tag#2 CDB: Write(16) 8a 00 00 00 00 00 e8 23 76 10 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804542] sd 2:0:0:2: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT > May 17 22:53:43 gserv kernel: [ 504.804545] sd 2:0:0:2: [sdc] tag#4 CDB: Write(16) 8a 00 00 00 00 00 e8 23 75 10 00 00 01 00 00 00 > May 17 22:53:43 gserv kernel: [ 504.804600] scsi host2: uas_eh_bus_reset_handler start > May 17 22:53:44 gserv kernel: [ 504.924432] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > May 17 22:53:44 gserv kernel: [ 504.946883] scsi host2: uas_eh_bus_reset_handler success > > These keep repeating unitl the filesystem driver (or the user) stops the transfer. > > I first was suspecting a hardware bug, but after playing around I found that thing seem to be OK once I use usb-storage instead of uas. If I add the following line to the modprobe blacklist > > $ ~> cat /etc/modprobe.d/blacklist_uas.conf > options usb-storage quirks=152d:0567:u > > the JMS567 bridge uses usb-storage instead and things seem to work smoothly (tested for a day with quite some copy operations). My conclusion from this is that either UAS is broken for this device or the device features used by uas are broken. > I think this means that either uas should by default blacklist this device or needs a fix. > > Let me know if you need additional information. > > Cheers, > Christoph > > > > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
