Red Hat Bugzilla – Bug 727579
Kernel 2.6.40 has an impressive power regression on thinkpad x220
Last modified: 2012-11-09 11:46:01 EST
After upgrading to kernel 2.6.40 I saw in impressive increase in power usage on my new thinkpad x220. (core-i5 2410M)
When ideling I cannot get under a power usage for 13 watts (measured by powertop).
When booting the 2.6.38 kernel the usage goes down to 8 watts.
Camera, fingerprint reader, bluetooth and express card slot is disabled by bios. I set pcie_aspm=force on kernel command line for both kernels.
powertop gives me no hint where the problem may come from.
Seems to be device specific. I don't see such an increase of power consumption on an eeepc-1005HA with an atom270. Actually there kernel 2.6.40 uses a little less power.
there's an i915_enable_rc6 option for i915.ko that might be relevant here.
It is - and setting it via the kernel commandline helps. Without, the power consumption is as catastrophic as described.
enabling it by default in 3.0 caused regressions for some people, so it was disabled. Hopefully Intel figures it out, and we can switch it back on by default in 3.1 / 2.6.41 (until then, you'll have to set it by hand).
(In reply to comment #3)
> It is - and setting it via the kernel commandline helps. Without, the power
> consumption is as catastrophic as described.
where I put this ? in grub.conf kernel boot option ? just i915_enable_rc6 is enough ?
kernel (...) i915_enable_rc6
I use additionally pcie_aspm=force to avoid the increased power consumption since kernel 2.6.38
*** Bug 742817 has been marked as a duplicate of this bug. ***
I noticed the same on my X220 (i7-2620M), enable_rc6 helps, but pcie_aspm leads to file system corruption on the SD card reader - does anyone else see this? I'm on F16 Beta.
I have experienced such problems with SD cards - but didn't test whether they are acutally caused by the aspm force.
The problem with the SD card reader on the thinkpad X220 is a separate issue, recently resolved, in bug #722509.
thanks! interesting, as it was triggered by pcie_aspm in my tests, but with the setpci's everything is working fine.
The 18.104.22.168 update enables rc6 again. Can you retest ?
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15.
In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.
Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.
I believe this bug appears in current F17 x86_64, kernel 3.6.3-1.fc17.x86_64.
I can reliably reproduce the behavior by suspending and resuming my x220 (type 4286CTO, add'l hardware configuration info available on request). I can also reliably work around it by adding "i915.i915_enable_rc6=1" to the kernel boot configuration. I've done several iterations of cold boot, run sudo powertop, suspend, resume, watch wattage soar (or not).
Without the kernel option, power usage roughly doubles on my system and stays there, compared to with.
Apologies for any muddying here. But I kept running additional tests, and now sometimes the fix is *not* working. The GPU shows pegged at 100% active, which I believe is an indicator for what's dragging the power. But it's not reliably doing this based on the kernel option any more. So I'll close this again, run additional tests, and report a clean bug once I can narrow it down.
(In reply to comment #15)
> Apologies for any muddying here. But I kept running additional tests, and
> now sometimes the fix is *not* working. The GPU shows pegged at 100%
> active, which I believe is an indicator for what's dragging the power. But
> it's not reliably doing this based on the kernel option any more. So I'll
> close this again, run additional tests, and report a clean bug once I can
> narrow it down.
You might be seeing bug 866212