cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.

Thanks for your bug report. With which version of Ubuntu and the kernel did you notice this? Thanks in advance.

It was on an rc for 2.6.20. I don't know exactly which one, probably rc3. I'll have to check if it's still a problem -- I'll get back to you on this when I have some time tonight!

I experience the exact same behavior with my Core Duo 2GHz Fujitsu-Siemens Lifebook. I run Ubuntu 6.10 with the 2.6.17-11-generic kernel.

Same deal happens in Edgy x86 on a Thinkpad T60p and Feisty x86 on a Uniwill X20II1 (both have Core2 Duo) when suspend-to-disk. My fix is to append the following to /etc/acpi/resume.d/69-services.sh after #!/bin/sh

# fix for second core scaling
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

No need to restart powernowd or echo ondemand to the scaling_governor file on resume from suspend.

There's a couple of options here.

  (a) have the kernel remember the choice (already does for the first CPU)
  (b) hack around and save this value in 'acpi-support'

Ideally the kernel should be doing this. 'powernowd' isn't run these days as a daemon, only an 'init.d' script to choose 'ondemand' and to load the appropriate modules.

Could you with multi-CPU machines please post the output from:

  $ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_[dg]*

before and after a suspend/resume cycle.

And if you have time, also after a hibernate/resume cycle.

Many Thanks, -Paul

<BenC> sladen: I just confirmed that problem on my core2duo workstation
<BenC> cpu1 reverted to performance
<BenC> cpu0 is at ondemand

Looks like the policy for this cpu is getting dropped during the suspend. Not sure if this is multi-core related, or just SMP in general.

I can reproduce it, so I'll check into the issue.

This is going to have to be fixed in userspace. The reason we lose the cpufreq state is because on suspend, the kernel hot unplugs the CPU, thus losing all referenced to it.

Userspace is going to need to respond to hot plug/unplug of cpu's and restore things like governor and frequency. Probably can do this with some udev rules, and remove the need for the init script all together. Maybe the init/udev scripts could check of cpu hotplug is enabled, and act accordingly (use init when it isn't supported and udev scripts when it is).

In the long-run, CPU hotplug seems to the way to fix this (that way the correct modules can also be loaded at that point). For the moment I think I'll fix it in 'acpi-support' by having the suspend and resume scripts save the scaling-governor during suspend/resume; in reality *everything* under that directory really needs saving.