Opened 11 years ago
Closed 10 years ago
#552 closed defect (fixed)
JMicron 152d:0539 JMS539 with bcdDevice 1.00 requires -d sat in conflict with existing drivedb.h entry
| 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 )
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
Attachments (1)
Change History (10)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Milestone: | → Release 6.5 |
|---|---|
| Owner: | set to |
| Status: | new → accepted |
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 , 10 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 , 10 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 , 10 years ago
| Description: | modified (diff) |
|---|
comment:6 by , 10 years ago
I found a Windows laptop and managed to update the firmware. The enclosure now identifies as 152d:0551 just like my other box, and my problems seem to be gone, knock on wood.
If there's interest i could provide the firmware i got from SSI.
comment:7 by , 10 years ago
You can add it as attachment to this ticket and also mention it in the usb wiki section, so hopefully other users will be able to find it this way.
by , 10 years ago
| Attachment: | DLSIN 1359RSUSI3 oFW.zip added |
|---|
Firmware update that turned broken 152d:0539 into working 152d:0551, needs Windows to run.
comment:8 by , 10 years ago
It's worth mentioning that updating with the attached firmware removes the annoying feature where the box will go into sleep mode after a few minutes of disuse.
comment:9 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |

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.