When the drive is configured 512e, there is no problem. When the drive is configured 4K Native, running "smartctl --xall pd1" results in an infinite loading condition and the only way to stop it is to unplug the drive. This only happens over USB and works fine over a direct SATA connection. It's worth noting I have tested a lot of drives over USB and this is the only time I have seen this issue.

The drive was originally 512e, but was changed to 4K Native using this tool: ​https://github.com/pig1800/WD4kConverter

Disk model: ​WDC WD4005FZBX-00K5WB0 (WD Black 4 TB 3.5") USB docking station: ​Sabrent DS-UTC1

I believe the chipset on the docking station is the ​ASMedia ASM235CM.

When the drive is unplugged, smartctl immediately returns the attached information (there are many errors).

The LED activity light on the docking station blinks the whole time and never stops until it's powered off.

My theory is that the the USB chip can't handle one of the commands you are sending. It's a bit odd it took a sector size change to expose the issue, though.

I have a WD Black 4 TB 3.5" HDD and smartctl indicates it is not in the drive database as of version 7.3/5319.

Product page: ​​https://www.westerndigital.com/products/internal-drives/wd-black-desktop-sata-hdd#WD4005FZBX

I have followed the instructions in your FAQ and have attached the test/report.

If you need any other technical details from my drive, I will be happy to provide them.

Note: The drive was originally 512e, but was changed to 4K Native using this tool: ​​https://github.com/pig1800/WD4kConverter (if that actually makes a difference in the drivedb?)

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.