Fixing an SSD Freezing on Windows 7
Archived note. Originally published 14 October 2012 on iishacks.com. It describes an Intel 520 series solid-state drive under Windows 7 with the Intel Rapid Storage Technology driver, as that combination behaved at that time, and is preserved here as a record. Windows 7 is long past end of support, and the drive firmware and storage drivers involved were revised repeatedly in the years that followed, so the registry change below should be treated as a diagnostic of its period rather than as current advice. Verify against current vendor documentation before applying any of it to a live system.
The symptom as it was recorded
A new Intel 520 series SSD was installed in a Thinkpad W520. No issues appeared for the first few weeks, until two virtual machines were run at once. There was then a stuttering — a freeze — every 60 to 90 seconds, lasting about 10 seconds each time. Performance Monitor showed the disk queue very high during the stalls: the maximum queue read over 3,500.
The original note recorded the rule of thumb it was working from: there is a relationship between current and average queue, but a length of about 2 per disk is reasonable. Any more than that for an extended period indicates a disk bottleneck. That reasoning is set out at greater length in the earlier note on high average disk queue length and finding the cause, which this post cited.
The cause
Intel Rapid Storage Technology is the culprit — specifically LPM (Link Power Management) and DIPM (Device Initiated Power Management). Both are recommended to be enabled, as they lower power consumption on SATA devices that support it, but in certain circumstances they may cause freezing, stuttering and other undesirable performance degradation.
The change
To turn off LPM and DIPM, the text below was saved from Notepad as LPM.reg and run. It disables LPM and DIPM for all SATA ports on the machine; to disable it for one port only, delete the other keys.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port0]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port1]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port2]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port3]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port4]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port5]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000This applies to a machine using the Intel Rapid Storage Technology driver only — the keys live under that driver's service, so a system running the Microsoft default AHCI driver is not covered by it. A restart is required after running the file.
Afterwards the Intel SSD Toolbox shows a warning in its system tuner. That is expected: the setting it objects to was disabled deliberately, and its Tune! button should not be clicked, because that puts the setting back.
What SATA link power management does
SATA defines low-power states for the link between the host controller and the drive — not for the drive's own electronics, but for the serial connection itself. When no commands are outstanding the link can be placed into a partial state, from which it recovers quickly, or into a deeper slumber state, which saves more power and takes longer to come back from. On a laptop running on battery this is worth having; the link spends most of its life idle, and keeping it fully powered for that idle time is wasted energy.
The two settings named in the registry file control who may initiate that transition. Host-initiated link power management lets the controller drop the link into a low-power state when the queue empties; device-initiated power management lets the drive make the same request from its end. Enabling both is the aggressive configuration, and it is what the driver of the period shipped and recommended.
Why it went wrong on early SSDs
The mechanism is a negotiation between two independent state machines — the host controller's and the drive controller's — over when to sleep and how to wake. Getting that right is firmware work on both sides, and in 2011 and 2012 the SSD half of it was young: controllers were being revised rapidly, firmware releases were frequent, and the combinations actually in the field were numerous and lightly tested against one another.
The failure mode that produced this symptom is a wake-up that does not complete cleanly. The link is asleep, a command arrives, the resume takes far longer than it should or has to be retried, and until it completes nothing is served. Requests continue to arrive from the operating system throughout, which is why the queue does not merely rise but explodes — a queue maximum over 3,500 is not a device that is busy, it is a device that has stopped answering while work keeps being handed to it.
The two-virtual-machine detail in the original note fits that reading exactly. A single desktop workload is bursty with long idle gaps and shallow queues; the stall either does not occur or is short enough to pass unnoticed. Two virtual machines produce continuous small random IO, so the link cycles into and out of low-power states constantly, meeting the bad transition far more often and with far more queued work behind it when it does.
Reasoning about the symptom rather than applying the fix
The registry change belongs to its hardware and driver generation and should not be applied by reflex. The shape of the diagnosis, though, is durable, and it is the part worth carrying forward.
- Periodic, not proportional. A stall that arrives on a roughly regular cycle and lasts a roughly fixed time is not a capacity problem. Saturation gets steadily worse as load rises; this does not. Something is entering a state and taking a fixed cost to leave it.
- Queue depth spiking to an absurd number. A queue in the thousands against a device rated for a few dozen outstanding commands means the device is not draining at all. That distinguishes a stalled device from a busy one.
- Latency, not queue length, is the measurement to take.
Avg. Disk sec/ReadandAvg. Disk sec/Writeduring the stall show individual requests taking seconds — not a figure any healthy device produces under any load. - Suspect power management first for a periodic stall. Link power states, drive idle timers, controller power policy and platform power plans all act on a timer, and a timer is what a periodic symptom implies.
- Change one setting and re-measure. Disabling a power feature is a diagnostic step and should be treated as one. What confirms it is the same Performance Monitor trace taken again under the same workload, not an impression that things feel better.
The trade should also be stated plainly, because the original note did not: disabling link power management costs battery life on a portable machine, and on a system that was already stable it costs that for nothing. It is a change to make against a measured symptom, not everywhere.
Related disk and drive material is collected under the hardware category, operating-system notes under Windows and Server, and every original post is indexed at post archives. For anything running on a supported system, the Windows Server troubleshooting documentation is the current starting point, and support dates can be checked on the Microsoft product lifecycle pages.