hdparm error: SG_IO: bad/missing sense data

I'm trying hdparm in Kali Live to add a ATA password to my Micron M600 Self-encrypted SSD, I use: hdparm --security-set-pass PASSWORD sda

But I get:

sda:  Issuing SECURITY_SET_PASS command, password="PASSWORD",
user=user, mode=high SG_IO: bad/missing sense data, sb[]:  70 00 05 00
00 00 00 0a 04 51 60 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00

So why does this happen?

When I type hdparm -I sda, it shows my drive is "security frozen", I remember that means I cannot change any security settings including add ATA password, is that the problem?

My BIOS doesn't support ATA password, and I've never set it before.

EDIT: The Security part of hdparm -I:

Security: 

    Master password revision code = 65534
            supported
    not     enabled
    not     locked
            frozen
    not     expired: security count
            supported: enhanced erase
    2min for SECURITY ERASE UNIT. 
    2min for ENHANCED SECURITY ERASE UNIT.

The format on this website is always messed up, but I try my best to keep the contant readable.

Partial answer, because it's too long for a comment:

The sense data given reads:

70  response code=Current information (about the error etc.)
00
05  sense code=Illegal Request
00 00 00 00 (not valid)
0a  additional 10 bytes
04 51 60 00  (command specific)
21 04 additional sense code=Unaligned Write Command
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So the error is "Illegal Request, Unaligned Write Command". That doesn't make particular sense if hdparm is using an ATA writethrough SCSI command.

I have no idea why this happens. If it's the reaction to the "security frozen" state, it's a really strange reaction. Possibly something in the SCSI-to-SSD translation layers doesn't like the ATA write through command?

Do you know for sure the Micron M600 SSD supports ATA passwords?

Edit: The manual you linked says:

Micron's SEDs support either the TCG Opal 2.0 specification or the ATA SECURITY FEATURE SET. The ATA security modes are generally initiated by system BIOS or by some universal extensible firmware interface (UEFI)-based systems in legacy mode. By specification from the associated industry standards organizations, TCG Opal and ATA security are mutually exclusive. In other words, if one is enabled, the other is disabled.

So if your BIOS doesn't enable it, it won't work. "Frozen" just means you can't change the state.

Please edit your question with the full output in the Security section of hdparm -I.

Edit

The hdparm -I output clearly says "not enabled", but "frozen". So your BIOS didn't enable it, but froze, so you can't change the state.

That means your SSD is in TCG Opal mode, and I've no idea how to access that under Linux.

Power cycling it while plugged is worth a try.

If you can find another computer with a BIOS that let's you set the password, or that doesn't freeze it, you can try it that way, too.

Had the same problem and I read in other places a power- or hotplug-cycle of the device would unfreeze it. Some people suggested to suspend the system in case of laptops, so I decided to try that and it worked!

So here's what I did to "unfreeze" the drive (it's on a remote server at hetzner hosting company):

First I booted the server into nfs-booted rescue environment. Then I logged in and suspended the system:

local $> ssh root@server    
server #> apt-get install pm-utils
server #> pm-suspend

At this point the system is suspended (also the SSD), my ssh shell unresponsive, of course.

I issued WOL (wake on lan) signal using the hosters control panel (not sure if a ping would've done the trick or not), after a while (20 seconds or so), the shell came back to life and the SSD was unfrozen so I could issue the --secure-erase command using hdparm as described in many howtos.

None of the answers above worked for me. But this one did:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I fixed the frozen state of my internal SSD by removing it and then reinserting it into the laptop while the laptop was on. (I was booting up from a DVD.)

Then I needed to set a security password in order to run the --secure-erase & --secure-erase-enhanced commands.

The password will automatically get cleared after the erase.

I ran into the same issue, with the exact same faultcode. This was on a dell system. I followed the arch wiki https://wiki.archlinux.org/index.php/Solid_state_drive/Memory_cell_clearing

It clearly states:

Set the Internal HDD Password in the BIOS (be careful, the keymap is en_US / qwerty).

I have a different keyboard layout, so basically, was using the wrong password the whole time ...