Comment 135 for bug 578673

I think I identified the problem on my system Dell Latitude E6410 with Intel i7 CPU.
Disabling Intel SpeedStep feature in BIOS does the trick. Battery life decrease seems insignificant thanks to power management assured by CPU C-states. What's interesting that the CPU multiplier is still variable (according to i7z) even with SpeedStep disabled, though the very low frequencies and turbo-boost frequency are never reached in contrast with SpeedStep enabled setup with ondemand governor.

Successfully tested on 20 consecutive suspend/resume cycles on battery, same on AC power.

Why does resume with SpeedStep enabled *only* fail when the machine is running on battery power remains unknown. Before forcibly disabling SpeedStep in BIOS I did a lot of different tests, disabling any possible PM scripts which either modified CPU governors (as e.g. /usr/lib/pm-utils/sleep.d/94cpufreq seems to do) or report the power state to other scripts (like /usr/lib/pm-utils/functions) forcing it to report that the machine is on AC-power even though it was not. Nothing was reliable enough.

Is it a BIOS bug? Someone with Dell Latitude e6410, BIOS rev.A05, Intel i7 M 620@2.67GHz can report the resume behavior when running on batteries with SpeedStep enabled? Both variants with either nVidia or Intel GFX should suffer from the same problem (if my laptop is not unique...)