Bug 15295 - scaling_max_freq value lost upon suspend
Summary: scaling_max_freq value lost upon suspend
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
: 41292 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-02-14 01:19 UTC by Sophia Herzog
Modified: 2013-06-18 14:34 UTC (History)
6 users (show)

See Also:
Kernel Version: 3.6.7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Kernel Configuration (55.05 KB, text/plain)
2010-02-14 01:19 UTC, Sophia Herzog
Details
dmesg - Kernel Ring Buffer (120.95 KB, text/plain)
2010-02-14 01:23 UTC, Sophia Herzog
Details
Output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" before suspending (4.16 KB, text/plain)
2012-11-28 03:02 UTC, Sophia Herzog
Details
Output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" after suspending (4.16 KB, text/plain)
2012-11-28 03:03 UTC, Sophia Herzog
Details

Description Sophia Herzog 2010-02-14 01:19:57 UTC
Created attachment 25037 [details]
Kernel Configuration

Bug:
Altered scaling_max_freq should be preserved over suspend-cycles.

Steps to reproduce:
0. Compile and boot kernel according to the attached .config
1. Alter scaling_max_freq
2. Suspend to RAM and wake up
3. scaling_max_freq is set to it's maximum
Comment 1 Sophia Herzog 2010-02-14 01:23:08 UTC
Created attachment 25038 [details]
dmesg - Kernel Ring Buffer
Comment 2 Zhang Rui 2012-01-18 01:58:42 UTC
It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?
Comment 3 z_kvn 2012-02-26 04:22:13 UTC
Hello 

I can confirm this bug persists with below kernal

ThinkPad-X220 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

In my /etc/rc.local I have below script to change scaling_max_freq of four cores 

for i in 0 1 2 3; do echo 2400000 > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done

However after suspend, only CPU0 stays 2400000, all other three changed to maximum of 2401000
Comment 4 Zhang Rui 2012-11-28 02:08:47 UTC
please attach the output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" both before and after suspend.
Comment 5 Sophia Herzog 2012-11-28 03:02:59 UTC
Created attachment 87471 [details]
Output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" before suspending
Comment 6 Sophia Herzog 2012-11-28 03:03:29 UTC
Created attachment 87481 [details]
Output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" after suspending
Comment 7 Sophia Herzog 2012-11-28 03:06:02 UTC
Last reproduced using Linux 3.6.7 on x86_64
Comment 8 Aaron Lu 2013-06-09 08:16:37 UTC
Hi Sophia & z_kvn,

I believe the following commit should fix this issue:

commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Wed May 15 21:47:17 2013 +0200

    cpufreq: Preserve sysfs files across suspend/resume

I've tested locally and it works for me, but it would be good if you can give it a test too, v3.10-rc2 above kernels are required, thanks.
Comment 9 Aaron Lu 2013-06-09 08:19:37 UTC
*** Bug 41292 has been marked as a duplicate of this bug. ***
Comment 10 Lan Tianyu 2013-06-09 08:25:31 UTC
Hi, Please check whether this bug still exists on the v3.10-rc4. If yes, try intel_pstate driver again. Thanks.
Comment 11 Lan Tianyu 2013-06-09 08:47:29 UTC
... Overlap. Anyway please try newest kernel.
Comment 12 Aaron Lu 2013-06-18 03:10:40 UTC
Hi Rafael,

Should the commit mentioned in comment #8 go into stable tree?
Comment 13 Rafael J. Wysocki 2013-06-18 13:25:13 UTC
On Tuesday, June 18, 2013 03:10:40 AM bugzilla-daemon@bugzilla.kernel.org wrote:

> --- Comment #12 from Aaron Lu <aaron.lu@intel.com>  2013-06-18 03:10:40 ---
> Hi Rafael,
> 
> Should the commit mentioned in comment #8 go into stable tree?

I believe so.

I also think that this bug may be closed.
Comment 14 Aaron Lu 2013-06-18 14:34:10 UTC
I agree. I just want to be sure after user confirmed, but looks like he is not available any more, so I'll close it.

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