Bug 8581

Summary:	acpi-cpufreq gets very confused on suspend to ram
Product:	Power Management	Reporter:	Elias Oltmanns (eo)
Component:	cpufreq	Assignee:	Dave Jones (davej)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	bhasker
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.21.3	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	7216
Attachments:	Applies to 2.6.23.1

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. ***