Showing results for 
Search instead for 
Did you mean: 
Community Manager

Intel 520 - Password not accepted after restart


I installed new Intel 520 SSD into my T420s and it works great with one exception - HDD password configured in BIOS is not accepted after restart. Both user and master passwords were configured for the drive but none is accepted after restart.

There is no issue with password when laptop is powered on or resumed from hibernation.

I had Intel 320 SSD before and it worked correctly in the same setup.

Thank you for help


Tags (1)
9 Replies
Community Manager


I have exactly the same problem. Switching from a 320 to a 520 the SATA password is not accepted after a restart on a Lenovo x220

With best regards, Lars

Community Manager

I'm having the same problem with a ThinkPad W530 and an Intel 520 SSD. The password is accepted if I shut down completely, but not after a reboot.

Community Manager

If the BIOS is asking for the ATA, SATA, HDD, etc. password on just a reboot, sleep, hibernation, etc., the BIOS / software has surely sent the drive the lock command. In the high security mode (passwords are set), you have to actually power down the drive to release that.

Encrypted drives, their commands, and how they interact with various versions of BIOS are not completely figured out. Odd things like this are pretty common. There are few possible things to try with the usual giant warnings and cautions involved in trying to change anything...

1. The computer maker might have updated BIOS that fixes this.

2. The software that is shutting down the computer might have shutdown options that will not lock the drive.

3. The BIOS security or HDD settings might be able to disable hard drive locking on a simple reboot.

4. You might try some live CD like Linux to see if it still does it. That would tell you if it is in the BIOS or something the running software is doing.

If it really bothers you a lot and none of the above show any hope, you will probably have to disable hibernation, sleep, etc. or remove the ATA passwords. Of course, then you lose the high security all together. If you need the security, you will have to just cold boot and you might as well just set the computer to turn off all the time if you are not using it.

There are actually good arguments for doing it many ways. Unfortunately, there are often not user options to set it the way "you" want...

BTW - No Secure drive will accept the ATA password after cold boot anyway since any simple spy software could easily steal the password then. You have to avoid letting the BIOS or software secure locking the drive if you want to be able to warm reboot.

Community Manager

piranha, I believe you misread the original post. It's true that the computer asks for the password upon a reboot, even if the BIOS setting for that is disabled, but the real problem is that the correct password is not accepted at the prompt. You have to power off the machine entirely and then turn it back on before it will accept the correct password. Having to enter the password after every reboot is annoying, but not nearly as annoying as when it asks and won't accept the correct answer.

This happens from both Windows 8 and Xubuntu 12.10, so it's not an operating system problem. It does NOT happen if you reboot from the BIOS screen, however.

Community Manager

Since it does it under Windows and Xubuntu the problem is in the computer's BIOS.

The BIOS is locking the drive and then asking for a password on a warm boot. Once the BIOS sends the lock command to the drive it will not respond to much of anything unless the power is cycled. So the BIOS locks the drive, then sees that the drive requires a password, and send the password to the drive. But the locked drive will not unlock unless the power is turned off and back on even with the correct password. The drive locking of this type is supposed to do that, but the BIOS is messing everything up.

So the BIOS is definitely weird there. Hopefully there is an update for it.

The BIOS should not send the lock command to the drive. Normally once the drive is powered up and has a good password, you should never have to reenter the pass and nothing should be locking the drive. But the BIOS is programed wrong for encrypting drives. It would be interesting to see if it does that with a standard drive too. But they should not have the high security locking that encrypting drives do so it is probably just an issue with drives like the 520. The BIOS maker never tested the BIOS on a high security drive...

Here is an article about the drive parameters in question: ATA Secure Erase - ata Wiki

Step 1a - Ensure the drive is not frozen:


Master password revision code = 65534


not enabled

not locked

not frozen

not expired: security count

supported: enhanced erase


If the command output shows "frozen" (instead of "not frozen") then you cannot continue to the next step.

Many BIOSes will protect your drives if you have a password set (security enabled) by issuing a SECURITY FREEZE command before booting an operating system. If your drive is frozen, and it has a password enabled, try removing the password using the BIOS and powering down the system to see if that disables the freeze. Otherwise you may need to use a different motherboard (with a different BIOS).

A possible solution for SATA drives is hot-(re)plug the data cable (this might crash your kernel). If hot-(re)pluging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables.

  • It has been reported that hooking up the drive to an eSATA SIIG ExpressCard/54 with an eSATA enclosure will leave the drive security state to "not frozen".
  • Placing my system into "sleep" (Clevo M865TU notebook) worked too---and this may reset other drives to "not frozen" as well. This also worked on my Lenovo Y580 with a Mushkin mSATA.
  • Users have also reported that IDE Drives may be unfreezed by plugging in an IDE cable to a CD-ROM first, booting your system and then moving the IDE cable to the drive in question. This will allow you to bypass "SECURITY FREEZE" commands sent by BIOS and your OS. BE AWARE, that IDE cables are not hot-pluggable and this technique possesses even higher risks; under no circumstances should you connect/disconnect/swap power cables of an HDD or CD-ROM, when your PC is on.

So your BIOS is sending the "SECURITY FREEZE" the the drive. The ATA wiki article is pretty technical but ti does show all the horrible basics of what is going on there. Unfortunately, there is nothing you can do about it short of getting a fixed BIOS update.


Community Manager

That makes sense and I agree that it is probably the BIOS at fault. However, the OP states that an Intel 320 SSD in the same setup worked correctly without this problem with the same BIOS. The problem seems to be unique to the combination of a ThinkPad BIOS and the 520 SSD.

Community Manager


So the firmware on the 320 and 520 drives might be different. I see they all say "400i" but there may be a dozen version of this 400i firmware too... I pulled the HD info off a 520 I had here and got the following:

mint@mint ~ $ sudo hdparm -I /dev/sdc


ATA device, with non-removable media

Model Number: INTEL SSDSC2CW120A3

Serial Number: CVCV223301VR120BGN

Firmware Revision: 400i

Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0


Used: unknown (minor revision code 0x0110)

Supported: 9 8 7 6 5

Likely used: 9


Logical max current

cylinders 16383 16383

heads 16 16

sectors/track 63 63


CHS current addressable sectors: 16514064

LBA user addressable sectors: 234441648

LBA48 user addressable sectors: 234441648

Logical Sector size: 512 bytes

Physical Sector size: 512 bytes

Logical Sector-0 offset: 0 bytes

device size with M = 1024*1024: 114473 MBytes

device size with M = 1000*1000: 120034 MBytes (120 GB)

cache/buffer size = unknown

Nominal Media Rotation Rate: Solid State Device


LBA, IORDY(can be disabled)

Queue depth: 32

Standby timer values: spec'd by Standard, no device specific minimum

R/W multiple sector transfer: Max = 16 Current = 16

Advanced power management level: 128

DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6

Cycle time: min=120ns recommended=120ns

PIO: pio0 pio1 pio2 pio3 pio4

Cycle time: no flow control=120ns IORDY flow control=120ns


Enabled Supported:

* SMART feature set

* Security Mode feature set

* Power Management feature set

* Write cache


* WRITE_BUFFER command

* READ_BUFFER command

* NOP cmd


* Advanced Power Management feature set

* 48-bit Address feature set

* Mandatory FLUSH_CACHE


* SMART error logging

* SMART self-test

* General Purpose Logging feature set

* 64-bit World wide name




* Gen1 signaling speed (1.5Gb/s)

* Gen2 signaling speed (3.0Gb/s)

* Native Command Queueing (NCQ)

* Host-initiated interface power management

* Phy event counters

* unknown 76[14]

* DMA Setup Auto-Activate optimization

Device-initiated interface power management

* Software settings preservation

* SMART Command Transport (SCT) feature set

* SCT Data Tables (AC5)

* Data Set Management TRIM supported (limit 1 block)

* Deterministic read data after TRIM


Master password revision code = 65534




not frozen

not expired: security count

supported: enhanced erase

Security level high


Logical Unit WWN Device Identifier: 5001517bb296403c

NAA : 5

IEEE OUI : 001517

Unique ID : bb296403c

Checksum: correct

mint@mint ~ $


Used: unknown (minor revision code 0x0110)

is interesting. I wonder how this compares to the 320 drive...


There is also the update tool: Download Center

But that might install different software for different drives too. Perhaps the toolbox application will give more info on the drive firmware and help see what the differences actually are.

I note that Toolbox version v1.93 was released far after OP's post. Aug. 17 vs. Nov. 27th. Who knows, maybe updating the 520's firmware to the latest version will fix it all. They list a lot of firmware revisions here:

<a href="http://downloa...

Community Manager

I can confirm that the same issue occurs with the T420 and T430 on both Intel 520 SSDs and the Intel 330 SSD (which is not a self encrypting drive). Trying to work with Lenovo to see if they can release a BIOS update that would fix this issue.


Problem still exists on my Lenovo T530 with latest BIOS 2.63 from 2015 and Intel 520 SSD.