Bug 1230336

Hans, should this be quirked in the kernel?  It seems ASMedia hardware is pretty sketchy all around, so I'm guessing so.

un 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#1 CDB: Write(10) 2a 00 0c 23 6f 30 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#2 CDB: Write(10) 2a 00 0c 23 70 20 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#3 CDB: Write(10) 2a 00 0c 23 71 10 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#7 CDB: Write(10) 2a 00 0c 23 72 00 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD IN 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#8 CDB: Read(10) 28 00 13 8f b4 f0 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD IN 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#9 CDB: Read(10) 28 00 13 8f b5 e0 00 00 20 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#10 CDB: Read(10) 28 00 13 8f b6 00 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD IN 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#11 CDB: Read(10) 28 00 13 8f b6 f0 00 00 f0 00
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN 
Jun 10 10:04:28 mp-host kernel: sd 12:0:0:0: [sdc] tag#12 CDB: Read(10) 28 00 13 8f b7 e0 00 00 20 00
Jun 10 10:04:28 mp-host kernel: scsi host12: uas_eh_bus_reset_handler start
Jun 10 10:04:28 mp-host kernel: usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
Jun 10 10:04:28 mp-host kernel: scsi host12: uas_eh_bus_reset_handler success

Hi,

Can you please plug in the driver, and then immediately afterwards do:

dmesg > dmesg.log

And check that dmesg.log contains the messages from the initial probing of the device?

Also please do:

lsusb -v -d 174c:55aa > lsusb.log

With the device plugged in, and then attach both log files here.

Thanks & Regards,

Hans

p.s.

Josh, I'm afraid it is not as simple as adding a quirk, the asmedia usb3<->sata bridges are very populair, and only the first generation has issues. Unfortunately one usb-id is used for all generations, so we have this beautiful code in the kernel to figure out what to do:

        /*
         * ASMedia has a number of usb3 to sata bridge chips, at the time of
         * this writing the following versions exist:
         * ASM1051 - no uas support version
         * ASM1051 - with broken (*) uas support
         * ASM1053 - with working uas support, but problems with large xfers   
         * ASM1153 - with working uas support
         *
         * Devices with these chips re-use a number of device-ids over the
         * entire line, so the device-id is useless to determine if we're
         * dealing with an ASM1051 (which we want to avoid).
         * 
         * The ASM1153 can be identified by config.MaxPower == 0,
         * where as the ASM105x models have config.MaxPower == 36.
         *
         * Differentiating between the ASM1053 and ASM1051 is trickier, when
         * connected over USB-3 we can look at the number of streams supported,
         * ASM1051 supports 32 streams, where as early ASM1053 versions support
         * 16 streams, newer ASM1053-s also support 32 streams, but have a
         * different prod-id.
         *
         * (*) ASM1051 chips do work with UAS with some disks (with the
         *     US_FL_NO_REPORT_OPCODES quirk), but are broken with other disks
         */
        if (le16_to_cpu(udev->descriptor.idVendor) == 0x174c &&
                        (le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
                         le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
                if (udev->actconfig->desc.bMaxPower == 0) {
                        /* ASM1153, do nothing */
                } else if (udev->speed < USB_SPEED_SUPER) {
                        /* No streams info, assume ASM1051 */
                        flags |= US_FL_IGNORE_UAS;
                } else if (usb_ss_max_streams(&eps[1]->ss_ep_comp) == 32) {
                        /* Possibly an ASM1051, disable uas */
                        flags |= US_FL_IGNORE_UAS;
                } else {
                        /* ASM1053, these have issues with large transfers */
                        flags |= US_FL_MAX_SECTORS_240;
                }
        }


Note that this already checks for the usb-id used by the reporter's device.

One more request, I see that you are using a 4.0.3 kernel, I'm not sure if that one already has all the fixes for different ASMedia generations can you try installing the 4.0.5 kernel, I just checked and that one does have all the fixes:

http://koji.fedoraproject.org/koji/buildinfo?buildID=644038

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.