Bug 8581 - acpi-cpufreq gets very confused on suspend to ram
Summary: acpi-cpufreq gets very confused on suspend to ram
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Dave Jones
URL:
Keywords:
: 9181 (view as bug list)
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2007-06-04 04:49 UTC by Elias Oltmanns
Modified: 2011-01-18 07:39 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.21.3
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Applies to 2.6.23.1 (2.09 KB, patch)
2007-10-21 06:13 UTC, Elias Oltmanns
Details | Diff

Description Elias Oltmanns 2007-06-04 04:49:02 UTC
Most recent kernel where this bug did *NOT* occur: Only switched to
acpi-cpufreq now.
Distribution: Ubuntu 06.10
Hardware Environment: Thinkpad X40
Software Environment:
Problem Description:
After startup acpi-cpufreq works as expected either running the
ondemand or the conservative governor. When using the conservative
governor, the cpu frequency stays at full speed after a suspend to ram
/ resume cycle. Switching to performance and back to conservative
seems to restore the usual behaviour.

Even more strange are the symptoms when running the ondemand governor.
A s2ram / resume cycle automatically switches to conservative, for
some reason, and I made a rather thorough search in /etc to ensure
that this is not due to some acpi, laptop-mode or similar script. At
least, cpu frequency drops to the lowest frequency but after a second
s2ram/resume cycle there it shows the same behaviour as described
above, i.e., frequency stays at full speed.
Comment 1 Elias Oltmanns 2007-06-04 05:41:38 UTC
Just for the record, speedstep-centrino which I've been using until
now still works as expected. In my configuration its switching the
cpufreq driver that triggers the problem. And there is another
difference although it might be known and considered a limitation
rather than a bug: Whereas the speedstep-centrino module apparently
can be unloaded during normal operation, the same does not apply to
acpi-cpufreq as the module is claimed to be in use even after
switching to the performance governor and setting everything to the
startup defaults.

Regards,

Elias
Comment 2 Rafael J. Wysocki 2007-08-08 10:11:25 UTC
Does the issue remain in the newest kernels (eg. 2.6.23-rc2)?
Comment 3 Rafael J. Wysocki 2007-09-23 05:26:31 UTC
There are some important fixes related to ACPI/suspend in the current Linus' tree (2.6.23-rc7-git4 as of today).  Can you test it please?
Comment 4 Rafael J. Wysocki 2007-10-06 08:38:36 UTC
Please test the 2.6.23-rc9 kernel or 2.6.23 final when it's out.

[I'm going to close this entry if there's no response in two weeks from now.]
Comment 5 Elias Oltmanns 2007-10-08 06:47:58 UTC
[Sorry for the delay.]

There still are some issues. On 2.6.22 and 2.6.23-rc9-git6 I see this
behaviour:

Driver: acpi-cpufreq
Governor: conservative

When issuing
echo mem > /sys/power/state
and resuming afterwards, /proc/cpuinfo reports maximum frequency. It
stays that way during normal operation until a more demanding process
is being launched. For instance when starting to compile the kernel,
the cpu is switched to the but lowest frequency (after some threshold,
of course) and behaves as expected from now on. So, there are two odd
things:
1. cpu stays at highest frequency after a suspend/resume cycle;
2. once there is enough load to trigger a frequency switching event,
   the switching algorithm behaves as if the cpu had been at the
   lowest frequency all the time, i.e., it steps through all the
   possible frequencies starting at the low end of the scale.
Comment 6 Rafael J. Wysocki 2007-10-12 12:48:37 UTC
Well, I'm not familiar with the cpufreq code.  I'll try to have a look at it, though (I can't promise that will be soon).
Comment 7 Elias Oltmanns 2007-10-21 06:13:07 UTC
Created attachment 13218 [details]
Applies to 2.6.23.1

Please apply the attached patch. Since it is a small one, I think it
should go to the stable team as well.
Comment 8 Dave Jones 2007-10-21 17:24:22 UTC
there's some whitespace damage in this patch (spaces instead of tabs).
Asides from that though, it looks like the right thing to do.
Can you fix that up, and bounce a copy to cpufreq@www.linux.org.uk please?

Thanks.
Comment 9 Elias Oltmanns 2007-11-21 04:51:42 UTC
Fixed in 2.6.24-rc3.
Comment 10 Len Brown 2011-01-18 07:39:35 UTC
*** Bug 9181 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.