Bug 1230336 - USB driver hangs/resets/locks machine for ASMedia (asm1051e) if USB quirks not used to disable uas [NEEDINFO]
Summary: USB driver hangs/resets/locks machine for ASMedia (asm1051e) if USB quirks no...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-10 16:53 UTC by fedora
Modified: 2015-11-23 17:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-23 17:15:48 UTC
Type: Bug
jforbes: needinfo?


Attachments (Terms of Use)

Description fedora 2015-06-10 16:53:10 UTC
Description of problem:

USB 3.0 ASMedia device with 1 Terrabyte drive mounted causes system to freeze temporarily, and sometimes permanently as the controller resets itself if usb-storage.quirks=174c:55aa:u is not set for boot


lsusb -v
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  idVendor           0x174c ASMedia Technology Inc.



lspci | grep USB
00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)


Version-Release number of selected component (if applicable):
Kernel version: 4.0.4-303


How reproducible:


Steps to Reproduce:
1. Attach pluggable usb 3.0 device to USB 3 port on Intel motherboard listed above
2. Perform any operation which scans the disk ( I used du -h from the root directory)


Actual results:
System freeze as the driver resets itself. Sometimes system does not recover.

Expected results:
USB 3 high speed results returned from device.

Additional info:
Related to original bug I filed for the Kernel version 3. I never disabled the USB-storage quirks flag so I only reexperienced the problem once upgrading to fedora 22.
https://bugzilla.redhat.com/show_bug.cgi?id=1121288



Journal log output to follow

Comment 1 Josh Boyer 2015-06-10 16:59:10 UTC
Hans, should this be quirked in the kernel?  It seems ASMedia hardware is pretty sketchy all around, so I'm guessing so.

Comment 2 fedora 2015-06-10 17:53:56 UTC
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

Comment 3 Hans de Goede 2015-06-11 08:02:26 UTC
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

Comment 4 Hans de Goede 2015-06-11 08:08:01 UTC
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.

Comment 5 Hans de Goede 2015-06-11 08:09:12 UTC
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

Comment 6 Justin M. Forbes 2015-10-20 19:27:53 UTC
*********** 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.

Comment 7 Fedora Kernel Team 2015-11-23 17:15:48 UTC
*********** 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.


Note You need to log in before you can comment on or make changes to this bug.