Re: High power consumption after suspend/resume cycle

Re: High power consumption after suspend/resume cycle

[Andrew Lutomirski]

[Adding cc's to linux-pm and linux-acpi and ]

On Fri, Oct 2, 2009 at 1:44 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> Hi all-
>
> I'm running a git kernel that's slightly newer than 2.6.32-rc1.
>
> First, thanks for all the great work everywhere on laptop power
> consumption -- on my Lenovo X200s, it looks like Linux is getting
> close to Windows (Windows wins by about 0.7W, except that its power
> usage frequently spikes since Windows apparently still doesn't know
> how to sit still and do nothing, whereas Linux's seems more stable.),
> even running KDE with compositing enabled and
> while connected to wifi, at least after some tweaking.

[fixed irrelevant typo above, too.]

>
> There's a catch, though: after a suspend/resume cycle, power
> consumption goes up by over well over a watt.  (On a system that draws
> about 7 watts before suspending, that's a big deal.)  I've tried
> turning off X, suspending with 'echo mem > /sys/power/state' to avoid
> any distro scripts running, and manually restoring SATA power saving
> settings, but it still happens.  I even tried unbinding e1000e and
> both USB drivers, unloading the i2400 (wimax) driver, iwlagn, and
> iwlcore, and it still happens.  This is 100% reproducible, and I'd be
> happy to test things.
>
> This could be a BIOS bug I suppose (although I'm running the latest
> BIOS), but Windows 7 does not have this problem at all.
>
> Any ideas about what to try or what subsystem to blame?
>
> I'm running Fedora 11 if that makes any difference.

This is actually more like 90% reproducible.  I've gotten it to stay
in low power after suspend a couple times with HAL disabled, but I
can't reliably reproduce *that*, either.

>
> Thanks,
> Andy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High power consumption after suspend/resume cycle

[Rafael J. Wysocki]

On Friday 02 October 2009, Andrew Lutomirski wrote:
> [Adding cc's to linux-pm and linux-acpi and ]
> 
> On Fri, Oct 2, 2009 at 1:44 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> > Hi all-
> >
> > I'm running a git kernel that's slightly newer than 2.6.32-rc1.
> >
> > First, thanks for all the great work everywhere on laptop power
> > consumption -- on my Lenovo X200s, it looks like Linux is getting
> > close to Windows (Windows wins by about 0.7W, except that its power
> > usage frequently spikes since Windows apparently still doesn't know
> > how to sit still and do nothing, whereas Linux's seems more stable.),
> > even running KDE with compositing enabled and
> > while connected to wifi, at least after some tweaking.
> 
> [fixed irrelevant typo above, too.]
> 
> >
> > There's a catch, though: after a suspend/resume cycle, power
> > consumption goes up by over well over a watt.  (On a system that draws
> > about 7 watts before suspending, that's a big deal.)  I've tried
> > turning off X, suspending with 'echo mem > /sys/power/state' to avoid
> > any distro scripts running, and manually restoring SATA power saving
> > settings, but it still happens.  I even tried unbinding e1000e and
> > both USB drivers, unloading the i2400 (wimax) driver, iwlagn, and
> > iwlcore, and it still happens.  This is 100% reproducible, and I'd be
> > happy to test things.
> >
> > This could be a BIOS bug I suppose (although I'm running the latest
> > BIOS), but Windows 7 does not have this problem at all.
> >
> > Any ideas about what to try or what subsystem to blame?

It's quite hard to say.  Most likely one of devices is put into the full power
state during resume and not put back into the low power state it was in before.

That may be a result of the PCI core handling of resume, which puts all devices
into D0 in order to restore their standard config registers and doesn't put
them into low power states afterwards.

If that's really the case, PCI run-time PM should help here once implemented,
although that's going to take some time to achieve.

Thanks,
Rafael

Re: High power consumption after suspend/resume cycle

[Andrew Lutomirski]

On Fri, Oct 2, 2009 at 5:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday 02 October 2009, Andrew Lutomirski wrote:
>> [Adding cc's to linux-pm and linux-acpi and ]
>>
>> On Fri, Oct 2, 2009 at 1:44 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> > Hi all-
>> >
>> > I'm running a git kernel that's slightly newer than 2.6.32-rc1.
>> >
>> > First, thanks for all the great work everywhere on laptop power
>> > consumption -- on my Lenovo X200s, it looks like Linux is getting
>> > close to Windows (Windows wins by about 0.7W, except that its power
>> > usage frequently spikes since Windows apparently still doesn't know
>> > how to sit still and do nothing, whereas Linux's seems more stable.),
>> > even running KDE with compositing enabled and
>> > while connected to wifi, at least after some tweaking.
>>
>> [fixed irrelevant typo above, too.]
>>
>> >
>> > There's a catch, though: after a suspend/resume cycle, power
>> > consumption goes up by over well over a watt.  (On a system that draws
>> > about 7 watts before suspending, that's a big deal.)  I've tried
>> > turning off X, suspending with 'echo mem > /sys/power/state' to avoid
>> > any distro scripts running, and manually restoring SATA power saving
>> > settings, but it still happens.  I even tried unbinding e1000e and
>> > both USB drivers, unloading the i2400 (wimax) driver, iwlagn, and
>> > iwlcore, and it still happens.  This is 100% reproducible, and I'd be
>> > happy to test things.
>> >
>> > This could be a BIOS bug I suppose (although I'm running the latest
>> > BIOS), but Windows 7 does not have this problem at all.
>> >
>> > Any ideas about what to try or what subsystem to blame?
>
> It's quite hard to say.  Most likely one of devices is put into the full power
> state during resume and not put back into the low power state it was in before.
>
> That may be a result of the PCI core handling of resume, which puts all devices
> into D0 in order to restore their standard config registers and doesn't put
> them into low power states afterwards.

I don't think that's the problem at all -- I diffed the output of
lspci -vvvvxxxx before and after suspend and none of the differences
looked interesting.  Everything was in D0 both before and after.  One
of the EHCI devices had PME asserted after resume, but clearing that
with setpci made no difference.

I did some more experiments that make it look like it's a bug in i915.
 I'll email the maintainers.

>
> If that's really the case, PCI run-time PM should help here once implemented,
> although that's going to take some time to achieve.

I'm looking forward to another little bit of power savings there, too :)

Thanks,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High power consumption after suspend/resume cycle

[The Holy ettlz]

[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]

Hello,

> > There's a catch, though: after a suspend/resume cycle, power
> > consumption goes up by over well over a watt.  (On a system that draws
> > about 7 watts before suspending, that's a big deal.)  I've tried
> > turning off X, suspending with 'echo mem > /sys/power/state' to avoid
> > any distro scripts running, and manually restoring SATA power saving
> > settings, but it still happens.  I even tried unbinding e1000e and
> > both USB drivers, unloading the i2400 (wimax) driver, iwlagn, and
> > iwlcore, and it still happens.  This is 100% reproducible, and I'd be
> > happy to test things.

Just out of curiosity: does it make any difference whether tickless mode
is enabled or not, and do you see an excess of wakeups with no apparent
origin, a la http://bugzilla.kernel.org/show_bug.cgi?id=12788 ?

Thanks,
James.

-- 
The Holy ettlz                              TheHolyettlz@googlemail.com
PGP key ID: 03F94B5D
-----------------------------------------------------------------------


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]