Bug 8671 - CPU frequency always on highest frequency after wakeup from suspend to disk
CPU frequency always on highest frequency after wakeup from suspend to disk
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: cpufreq
All Linux
: P1 low
Assigned To: cpufreq
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2007-06-25 05:01 UTC by Markus Schaub
Modified: 2007-08-09 07:14 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.22-rc5-git8
Tree: Mainline
Regression: ---


Attachments
Keep policy->user_policy in sync and use CPU0 policy as a template for other CPUs policy when up-ed (1.50 KB, patch)
2007-06-25 23:28 UTC, Mattia Dongili
Details | Diff
Restore previously used governor on a hot-replugged CPU (2.41 KB, patch)
2007-06-26 06:02 UTC, Thomas Renninger
Details | Diff

Description Markus Schaub 2007-06-25 05:01:18 UTC
Most recent kernel where this bug did not occur: unkown
Distribution: Gentoo Linux
Hardware Environment: IBM Thinkpad T43
Software Environment:
Problem Description: cpufreq_conservative doesn't scale CPU frequency anymore after wakeup from suspend to disk, instead CPU runs always with the highest available frequency. Scaling driver is acpi-cpufreq.

Steps to reproduce: Choose cpufreq_conservative as scaling driver and execute "echo disk > /sys/power/state".
Comment 1 Mattia Dongili 2007-06-25 06:37:49 UTC
aaaah, maybe that's because CPU1 is offlined and when resumed .init is called which sets the CPUFREQ_DEFAULT_GOVERNOR.
In fact after resume CPU1 has the performance governor here, could you check it's the case for you as well?

Any suggestion on how to solve that?
Maybe cpufreq_add_dev should set the CPU0 policy as default when other CPUs are up-ed?
Comment 2 Markus Schaub 2007-06-25 07:36:55 UTC
eerm, in fact that's a one processor system and /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor says that the conservative governer is active for CPU0.

/proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 2.00GHz
stepping        : 8
cpu MHz         : 800.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips        : 1597.58
clflush size    : 64
Comment 3 Mattia Dongili 2007-06-25 09:22:40 UTC
ops :)
does it happen with ondemand as well?
would you mind setting cpufreq debug=7
  echo 7 > /sys/module/cpufreq/parameters/debug
perform a suspend/resume cycle and attach the log?

thanks
Comment 4 Markus Schaub 2007-06-25 09:52:19 UTC
this is the debug log for cpufreq_conservative:
cpufreq-core: suspending cpu 0
swsusp: critical section: 
swsusp: Need to copy 14851 pages
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
cpufreq-core: resuming cpu 0
cpufreq-core: Warning: CPU frequencyis 2000000, cpufreq assumed 800000 kHz.
cpufreq-core: scaling loops_per_jiffy to 7987872for frequency 2000000 kHz
cpufreq-core: handle_update for cpu 0 called
cpufreq-core: updating policy for CPU 0
cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 kHz
cpufreq-core: new min and max freqs are 800000 - 2000000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
Comment 5 Markus Schaub 2007-06-25 09:59:02 UTC
ondemand seems to work well.
Comment 6 Mattia Dongili 2007-06-25 23:28:20 UTC
Created attachment 11881 [details]
Keep policy->user_policy in sync and use CPU0 policy as a template for other CPUs policy when up-ed
Comment 7 Mattia Dongili 2007-06-25 23:28:43 UTC
Markus, does the attached patch fixes it for you?
Comment 8 Markus Schaub 2007-06-26 04:39:22 UTC
No, the patch doesn't change anything (tested on 2.6.22-rc6).
Comment 9 Thomas Renninger 2007-06-26 06:02:00 UTC
Created attachment 11884 [details]
Restore previously used governor on a hot-replugged CPU

Can you try this one, pls.
Comment 10 Markus Schaub 2007-06-26 06:37:12 UTC
Yepp, the patch from Thomas works.
Comment 11 Mattia Dongili 2007-06-26 07:16:16 UTC
Comment on attachment 11881 [details]
Keep policy->user_policy in sync and use CPU0 policy as a template for other CPUs policy when up-ed

looks like Tomas had a better (and working) fix
Comment 12 Adrian Bunk 2007-06-30 16:57:35 UTC

*** This bug has been marked as a duplicate of bug 7216 ***
Comment 13 Adrian Bunk 2007-06-30 17:04:15 UTC
Sorry, wrong field.
Comment 14 Rafael J. Wysocki 2007-08-08 10:03:38 UTC
(In reply to comment #9)
> Created an attachment (id=11884) [details]
> Restore previously used governor on a hot-replugged CPU

Can you please tell me what the status of this patch is?
Comment 15 Dave Jones 2007-08-08 21:42:26 UTC
It's in Linus' tree for 2.6.23

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