Change JMicron JM20337/8 device type to sat

[Eaton Zveare]

I have 2 USB adapters, one with a JMicron JM20337/8 chip, and another with JMicron JM20339.

The JM20339 is set up to use "-d usbjmicron" in drivedb.

• When I run "smartctl --xall pd1", it prints everything.
• When I run "smartctl --xall -d sat pd1", it prints "Read Device Identity failed: scsi error unsupported scsi opcode".
• Experience with IDE_COMMAND_SECURITY_UNLOCK is described in this ticket.
• There is nothing wrong with the JM20339 drivedb entry.

On the other hand, the JM20337/8, appears to behave differently.

• When I run "smartctl --xall pd1", it prints everything.
• When I run "smartctl --xall -d sat pd1", it also prints everything.
• When I run a custom command (IDE_COMMAND_SECURITY_UNLOCK), letting it use the JMicron pass-through, the command appears successful. Sense data empty, no check condition. But, the disk was not unlocked. Attempting this 5 times, even with the wrong password, does not result in exceeded attempts.
• When I run a custom command (IDE_COMMAND_SECURITY_UNLOCK), this time specifying "-d sat", the command appears successful. Sense data empty, no check condition. 2 differences though:
  1. With the correct password, the disk is actually unlocked.
  2. With the wrong password, there is still no sense data or check condition, but after 5 attempts, security data indicates attempts exceeded.

The "custom command" code is described here.

Conclusion: It is slightly beneficial to change the JM20337/8 drivedb device type to sat in order to improve the chances of certain commands succeeding. Exact line to be changed
The JM20337/8 appears very buggy. It's even worse than the JM20339 which at least returned a check condition for failed commands. Changing JM20337/8 to sat makes a bad situation slightly better.

[Christian Franke]

The root of the entries for these bridges is 13+ years old, see r2755.

For some JMicron bridges apparently exist firmware versions which only support the legacy -d usbjmicron pass-through command and others which support only -d sat and even others which support both. If the bcdDevice values (often 0x0100 aka 1.00) differ, this could be solved with separate entries, except on Windows. If not, we should leave the entry unchanged to keep support for older devices.

Note that you could always add local drive database entries for your specific devices (see -B option).

Please provide the bcdDevice values for your devices (lsusb on Linux).

PS:

... Exact line to be changed

Please use TracLinks syntax and include the current file revision, otherwise the line number reference is not persistent: [source:/trunk/smartmontools/drivedb.h@5382#L5983 Example] Result: Example​.

[Eaton Zveare]

bcdDevice is 0x0100 on both.

[Christian Franke]

If bcdDevice does not differ, the newer(?) firmware cannot be detected.

[Eaton Zveare]

Hi Christian, wontfix? In this case it seems clear that -d sat works better than autodetect/-d usbjmicron. Are you sure you can't consider changing that 1 entry?

Keeping my own drivedb modification would be a pain, especially since this solution works and could benefit others.

[Christian Franke]

Sorry, no. This would break backward compatibility.

The JM20337/8/9 series are very old (<= 2004). Older revisions of JM20337/8 do not support -d sat. Different revisions apparently return the same bcdDevice.