Opened 9 years ago

Last modified 9 years ago

#552 closed defect

JMicron 152d:0539 JMS539 with bcdDevice 1.00 requires -d sat in conflict with existing drivedb.h entry — at Version 5

Reported by: Christoffer Hammarström Owned by: Christian Franke
Priority: major Milestone: Release 6.5
Component: drivedb Version: 6.3
Keywords: jmicron Cc:

Description (last modified by Alex Samorukov)

I recently got a new SSI-1359RUS3 hard drive enclosure (152d:0539 JMS539 with bcdDevice 1.00), because i had an identical box that i bought a few years back, that was working well (152d:0551).

The vendor page is at http://www.ssi.com.tw/en/goods.php?act=view&no=33

The only problem i had with the older box is that it's impossible to read smart data from the first drive in the box, but it otherwise works fine.

Apparently the boxes turn out to have different firmware, though they seem physically identical.

I'm running both boxes in JBOD mode.

When smartd tries to read from the first drive in the new box (152d:0539), the usb disconnects and reconnects, failing my raid.

It took me a while to figure out that the new box requires "-d sat", where drivedb.h has "-d usbjmicron". for "0x152d:0x0539", "0x0100".

I changed "-d usbjmicron" in that entry in my drivedb.h to "-d sat", and the usb no longer disconnects when smartd tries to read from the first disk in the box.

lsusb -v output follows:

# lsusb -d 152d:0539 -v

Bus 002 Device 012: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge
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          0x0539 JMS539 SuperSpeed SATA II 3.0G Bridge
  bcdDevice            1.00
  iManufacturer           1 JMicron
  iProduct                2 USB to ATA/ATAPI Bridge
  iSerial                 5 DCC4E6D917FF
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    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
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           42
  bNumDeviceCaps          3
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat          32 micro seconds
  Container ID Device Capability:
    bLength                20
    bDescriptorType        16
    bDevCapabilityType      4
    bReserved               0
    ContainerID             {00010203-0405-0607-0800-000000000000}
Device Status:     0x0001
  Self Powered

Change History (5)

comment:1 by Christoffer Hammarström, 9 years ago

Maybe i should mention that with -d sat i still get no smart data for the first drive in the box, but at least my raid doesn't fail.

comment:2 by Christian Franke, 9 years ago

Milestone: Release 6.5
Owner: set to Christian Franke
Status: newaccepted

Other (older?) versions of this USB bridge with bcdDevice 1.00 reportedly worked with -d usbjmicron. This means we could no longer autodetect the device type of this bridge if bcdDevice is 1.00. Other versions returning different bcdDevice values are not affected (tickets #338, #504).

Note that you could add a local entry for this device. The local drive database file will not be overwritten by update-smart-drivedb. See -B option on smartctl man page for the distribution specific path (/etc/smart_drivedb.h, /etc/smartmontools/smart_drivedb.h).

comment:3 by Christoffer Hammarström, 9 years ago

I mailed SSI tech support and got a firmware update.

It needs to be updated from Windows, so i tried from Windows in VirtualBox.
The firmware update didn't go through since the updating program errored out claiming the chipset was the wrong version.
The package with the firmware also included their Windows raid management program that i managed to run.

Since then, the drives now disconnect when i use "-d sat", and now "-d usbjmicron" works instead, even though i never applied the firmware update.

I'm thinking the raid manager may have done something.

comment:4 by Christoffer Hammarström, 9 years ago

And, i also did have to fiddle with my USB settings in the BIOS setup to get Virtualbox to work. Specifically i think i turned of xHCI hand-over. That might also have something to do with it.

comment:5 by Alex Samorukov, 9 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.