USB-SATA resets when UAS is used

[Michael Stockenhuber]

Dear developers,
I have a Icybox 4 HDD enclosure with a JMicrom JMS567 SATA to USB converter. When the device is under load and more than 1 hardrive is acessed, the USB enclosure frequently restarts. This leaves often a corrup filesystem. I tried to switch off UAS by creating a file in /etc/modprobe.d/blacklist_uas.conf with the following content:
options usb-storage quirks=152d:0567:u
This disables UAS, and I did not exerinecs restarts of the box. But of course thios laves only USB speeds on the USB3 connector, which is quite slow.
I think this suggest this is a kernel bug and not a hardware issues.
I aasume the problem is in the linux-image-4.15.0-33-generic package.
Similar has been reported:
https://www.spinics.net/lists/linux-usb/msg157550.html
Any help would be greatly appreciated.
Best regards
Michael

lsusb -vvv -s 003:004

Bus 003 Device 004: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Couldn't open device, some information will be missing
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 3.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct 0x0567 JMS567 SATA 6Gb/s bridge
  bcdDevice 2.05
  iManufacturer 10
  iProduct 11
  iSerial 5
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 44
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 2mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 6 SCSI
      bInterfaceProtocol 80 Bulk-Only
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0400 1x 1024 bytes
        bInterval 0
        bMaxBurst 15
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x02 EP 2 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0400 1x 1024 bytes
        bInterval 0
        bMaxBurst 15
res3stockm@brix:~$ lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: res3stockm 11358 F.... pulseaudio
 /dev/snd/controlC0: res3stockm 11358 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=3e40bf65-88c1-45fc-a2f5-7bc5e4bd2fff
MachineType: GIGABYTE MMLP3AP-00
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-33-generic root=UUID=daee2663-9ad7-4cac-b5b5-5176a8d4e589 ro quiet usbcore.autosuspend=-1 usbstoragequirks=0x152d:0x0567:f
ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-33-generic N/A
 linux-backports-modules-4.15.0-33-generic N/A
 linux-firmware 1.173.1
Tags: bionic
Uname: Linux 4.15.0-33-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-04-27 (139 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 02/19/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F5
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: MMLP3AP-00
dmi.board.vendor: GIGABYTE
dmi.board.version: 1.x
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 10
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF5:bd02/19/2014:svnGIGABYTE:pnMMLP3AP-00:pvr1.x:rvnGIGABYTE:rnMMLP3AP-00:rvr1.x:cvnToBeFilledByO.E.M.:ct10:cvrToBeFilledByO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: MMLP3AP-00
dmi.product.version: 1.x
dmi.sys.vendor: GIGABYTE

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1789589

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19-rc1/

[Michael Stockenhuber (michael-st)]

Dear all,
Tested with upstream kernel, same result.
Kernel version:
Linux version 4.19.0-041900rc1-generic (kernel@kathleen) (gcc version 8.2.0 (Ubuntu 8.2.0-4ubuntu1))
kernel-bug-exists-upstream

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Michael Stockenhuber (michael-st)]

apport information

[Kai-Heng Feng (kaihengfeng)]

Have you tried other quirks?

FWIW it's "usb-storage.quirks=" instead of "usbstoragequirks=".

[Hans de Goede (j-w-r-degoede)]

From the original report:

"When the device is under load and more than 1 hardrive is acessed, the USB enclosure frequently restarts."

So this very much sounds like a hardware problem. UAS allows having multiple outstanding commands (read/write requests) and thus *actually* accessing multiple disks at once.

If you disable UAS then there can be only 1 read *or* write requests be done at a time and only when that requests has fully completed, which requires 3 round-trips to the device, then the next request can be send.

So, especially when accessing multiple drives (or a SSD) using the old mass-storage USB protocol is much much slower. The slowness has one advantage though, if only 1 thing is done at a time / only 1 drive accesses at a time, then much less power is consumed by the driver.

Unfortunately this often causes people to believe that there is a bug in the UAS driver, where as the real problem is the power-supply of their disk enclosure not providing enough power.

"the USB enclosure frequently restarts." is exactly what one would expect with brown-out (voltage level getting too low) issues like this. So I'm 90% sure that this an issue with the power-supply used to power the enclosure either being bad, or simply not being powerful enough.

Note I used to be the upstream kernel maintainer for the Linux UAS driver for a number of years.

@kaihengfeng, this issue should probably be closed as not a bug or some such.

[Kai-Heng Feng (kaihengfeng)]

Hans,

Thanks for your detailed explanation!