Ubuntu
linux package

USB-SATA resets when UAS is used

Asked by 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

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu linux Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:

This question was originally filed as bug #1789589.

Revision history for this message
Kai-Heng Feng (kaihengfeng) said : 		#1

Hans,

Thanks for your detailed explanation!

Revision history for this message
Kai-Heng Feng (kaihengfeng) said : 		#2

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789589/comments/20
Quote from Hans:
"
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.
"

Can you help with this problem?

Provide an answer of your own, or ask Michael Stockenhuber for more information if necessary.

To post a message you must log in.