This USB bridge is not recognized as of drive database version 7.3/5364 and smartctl says: Unknown USB bridge [0x125f:0xa76a]

Any HDD can go in it, so I've attached some USB-specific information.

Product page: ​https://www.adata.com/en/consumer/537

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.

Despite the SSD comes with a newer firmware revision, it still seems to suffer from #1227 (fluctuating Current_Pending_Sector)