hdparm error: SG_IO: bad/missing sense data

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.

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.

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.