Comment 235 for bug 760131

After some more extensive testing I cannot confirm the regression anymore on my Panasonic CF-T5:
forcing pcie_aspm and manually setting powersave:

echo powersave > /sys/module/pcie_aspm/parameters/policy

solves the problem for me as well.
From /proc/cpuinfo:
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU U1400 @ 1.20GHz

I made a script for pm-powersave, attached as pcie_aspm, and put it in /etc/pm/power.d

I made a table to summarize the results of the tests, reporting powertop results on 4 hours
Wakeups/s (lower=better), C3% (perc. of time in higest C state, higher=better), PLow% (perc. of time
at lowest CPU freq, higher=better), battery duration (hh:mm, based on battery-stats log), avg temperatures
of the two available sensors (estimate based on collectd graphs). All tests were run with screen brightness
10/21, dpms on (switching off the screen after 10min), wifi off (in normal conditions the battery lasts less then
half the times obtained in the tests, but it's still pretty good).

Kernel | Wakeups/s | C3% | PLow% | Power | Battery | Temp0 C | Temp1 C |
2.6.35-28.50 +aspm 50.7 93.6 77.0 5.8W 15:15 38 39
2.6.38-11.50 +aspm 53.7 94.4 81.8 4.0W 16:23 37 38
2.6.38-12.51 +aspm a 47.2 94.1 84.6 8.7W 8:57 38 42
2.6.38-12.51 +aspm b 46.1 93.2 70.2 4.8W 14:52 38 39

The thing I realized running the tests is that acpi estimate of battery state (and power) is not so reliable,
therefore I had very different results with when starting the tests as soon as the charge was 100%, and
when it was left powered for a few hours while at 100%. That was the only difference among the two runs
with 2.6.38-12.51, marked a and b in the table. As you can see, repeating the test after some time with the
ac adapter plugged in gave me results which are comparable to maverick.

Thanks a lot to all contributors to this very long bug report!