CPU Frequency Scaling Monitor applet on dual-core doesn't work after resume

I confirm this, 2nd cpu seems not to respond to a governor option change after suspend/resume; removing and re-adding the applet corrects it.
With Gutsy's kernel 2.6.22 I don't see the problem right now. I will test it more extensively though and report if I see anything interesting.

Thank you for your bug. Marking confirmed since somebody else has the issue. Likely an upstream bug to send on bugzilla by somebody having a configuration to trigger the bug

I confirm this on my Lenovo T60p. However, this bug is not related to the applet but it is an acpi bug. In fact, there is no way I can change the frequency even using "cpufreq-set" or "cpufreq-selector".

not a gnome-applets bug

Fixed as of Gutsy Tribe-5 2.6.22-10-generic, with CPU Frequency Scaling Monitor 2.19.1

Also confirmed with a duo core 2. Removing one applet and placing anew is the only way I've seen around the problem.

Hi TJ, I'm running the new 7.10 Gutsy release (2.6.22-14-generic kernel) on my Dell Inspiron 1420 laptop with Intel(R) Core(TM)2 Duo CPU T7500 and using CPU Frequency Scaling Monitor 2.20,0 and can verify this bug still exists. I'm curious if you've noticed any regressions from Gutsy Tribe-5 to the new 7.10 Gusty release?

It does look as if this bug has returned. I'll dig into it.

Leann correctly marked my bug (141339) as a duplicate of this one.

On my system, running "/etc/init.d/powernowd restart" reliably fixes the problem. I created a script in /etc/acpi/resume.d with these contents:

#!/bin/sh
/etc/init.d/powernowd restart

This is automatically run when the system resumes, and should work if you're using acpid. Be sure to chmod a+x the file.

I was surprised that this works, as powernowd is disabled on my system (I'm using the ondemand governor), so the command doesn't actually cause the daemon to start up. However, /etc/init.d/powernowd sets CPU frequencies via proc/ and reloads kernel modules even when powernowd isn't being used. That's probably enough to get the kernel space governors to behave properly.

Does anyone see any substantial difference between this bug and bug #68191 or bug #183033? I'm thinking all 3 are dupes now.

I can seem to change governor, but after a resume I get the governor set to performance. This is on Hardy: Linux yensid 2.6.24-3-generic #1 SMP Thu Jan 3 23:30:29 UTC 2008 i686 GNU/Linux

I am quite sure that bug #183033 is a duplicate of this one. Bug #68191 seems to have a few different issues mixed in, one of them being this one.

For me, running /etc/init.d/powernowd restart does not help, apparently because some modules (like acpi-cpufreq) can't be unloaded.

I just attached a dmesg log, but by mistake attached it to a duplicate of this bug. The attachment is http://launchpadlibrarian.net/12134489/dmesg . It's from booting normally, working for a while, then suspending and resuming. The suspend begins at timestamp 5712. In particular, the line

[ 0.574649] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c3efb60), AE_NOT_FOUND

looks interesting. Could that affect cpufreq scaling?

I'm no kernel hacker, but that does look very interesting... in fact, the lines before and after look related as well:

[ 0.574636] ACPI Error (psloop-0136): Found unknown opcode 17 at AML address ffffc200008b27c3 offset 0, ignoring [20070126]
[ 0.574645] ACPI Error (psargs-0355): [DBþÿ] Namespace lookup failure, AE_NOT_FOUND
[ 0.574649] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c3efb60), AE_NOT_FOUND
[ 0.574685] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]
[ 0.574690] CPU1 is up

It seems that there's an issue with acpi just before CPU1 is brought up...

The bug that I posted may be a dupe, these seem pretty much the same.

I'm getting this problem on an up to date Hardy too.

Running a Core 2 Duo Lenovo R61.

Do you need any logs, specs etc?

I should probably also add that, ostensibly at least, restarting powernowd fixes the problem.

If I try and write this into one of the acpi scripts though it doesn't take effect.

Does anyone have any idea how to debug this further?

Care to test with the latest 2.6.24-10 ubuntu-kernel. If the issue still exists, care to attach your dmesg output after resuming from Suspend?

Also, please note that we will keep this report open against the currently developed kernel bug against 2.6.20 and 2.6.22 this will be closed. Thanks.

Is there a package that won't break gutsy that I can use to test, or will I have to install Hardy?

At the moment, there's not even a Hardy package since 2.6.24-10 is not in the archive: http://packages.ubuntu.com/search?keywords=linux-image-2.6.24&searchon=names&suite=hardy&section=all

What are you talking about? There is a 2.6.24-10 on that page for every arch that I can think of--can I install the hardy package on gutsy?

That 2.6.24-10 package appeared just in the last few hours. I wouldn't recommend installing it on Gutsy.

I've been running 2.6.24-? on gutsy for weeks with no real problems. If
you're worried, make sure it doesn't pull too much hardy stuff in...
Last I checked, 2.6.24 didn't require very many (any?) package upgrades.
  (I haven't had a chance to play with the most recent one...)

The old kernel should show up in grub, so you can still boot into it
after installing 2.6.24.

-Rusty

Johan Brannlund wrote:
> That 2.6.24-10 package appeared just in the last few hours. I wouldn't
> recommend installing it on Gutsy.
>

Nothing has changed with 2.6.24-10, the bug is still there. The dmesg is also basically the same, but I'm attaching it just in case. In particular, the suspicious ACPI errors mentioned above are still there.

According to Matthew Garrett, the ACPI errors are a good candidate for being the cause of this bug.

It seems that the ACPI team is taking care of it now (or at least they are assigned to it...)... COOL!

My system may be different than most, here's my specs:

Dell Vostro 1400
Intel Core 2 Duo @ 2.0 GHz
nVidia GeForce 8400 GS
3 GB Ram
160 GB Hard Disk w/ ~120 GB Linux partition

Something (in my situtation) that I think may be of interest too, I was unable to get my computer to successfully suspend or hibernate at all without modifying the hal scripts. Because I have an nVidia system, I believe that it is due to the vbetool (or similar ioctls) with my nVidia system. The hal scripts, by default, use powersave, but on my system powersave didn't work (probably because of the VBE thing). so I modified the hal scripts to give preference to the /etc/acpi scripts for suspend and hibernate. Could this be related to the issue as well?

I examined the original bug report from TJ and noted that before a resume, the state in /sys/devices/system/cpu/cpuN/cpufreq/scaling_governor for CPU's 0 and 1 on my laptop is "ondemand".
However after a resume they are reset to "performance", and not preserving the original "ondemand" state.

Now. running the command:

sudo /etc/acpi/sleep.sh sleep

does save the scaling_governor state (in script /etc/acpi/suspend.d/30-proc-sysfs-save-state.sh) to /var/run/proc-sysfs-save-state and the settings are restore on a resume - and the CPU Frequency Scaling Monitor Applet is displaying the correct CPU scaling settings.

However, it appears that these scripts are not called from the Gnome desktop when suspend is actioned (e.g. from the Quit->Suspend applet action), I presume the suspend is being performed by HAL. I which case, this is not a kernel bug, but an issue with Gnome/HAL not saving/restoring the /sys/devices/system/cpu/cpuN/cpufreq/scaling_governor states in a suspend/resume cycle.

The hal scripts in /usr/lib/hal/scripts/, specifically hal-system-power-suspend and hal-system-power-hibernate prefer to use powersaved if it is installed, but in my experience, powersaved does not work.

I modified these scripts to prefer acpi-scripts instead. I can upload a patch if you want.

Something else to note is that on my system, the stuff in /sys/devices/system/cpu is a bit different.

Before suspend, /sys/devices/system/cpu1/cpufreq is a symlink to /sys/devices/system/cpu0/cpufreq. After suspend, this symlink simply doesn't exist. Should this be open in a separate bug? I believe I already have done this, but it was decided that it was a dupe of this bug.

I'm not sure if this has been mentioned before, but if I unload (modprobe -r) acpi_cpufreq and reload it, the proper cpufreq directories and symlinks are restored.

For now, I'll will add this in the resume.d dir for /etc/acpi

I wonder if this is true w/ other cpufreq modules (k8, centrino)? The problem in the kernel is probably the cpufreq module.

Oh yeah, and sorry for the double post.

I just had a conversation with Colin King on IRC. This bug apparently conflates two issues:

1. The suspend scripts do not restore the cpufreq governor on resume.

2. The cpufreq support on core 1 disappears entirely on resume.

This bug now tracks issue 1, which has to do with HAL.

For issue 2, see bug #183033.

I believe this bug ("The suspend scripts do not restore the cpufreq governor on resume.") is the same as this other bug from 2006: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/64070

Marking confirmed as it can be reproduced here and as suggested in comment 30.

The remaining task here for hal has been fixed in a recent pm-utils upload.