After hibernation, powernowd only controls one CPU

[Stefan van der Walt]

Booting up my laptop (with an Intel Duo Core CPU) after it had hibernated, only CPU0 is controlled by powernowd. Restarting powernowd fixes the problem.

powernowd: 0.97-ubuntu1
kernel: 2.6.15-22-686

[Stefan Skotte (screemo)]

I get the very same error in the latest (k)ubuntu edgy:

powernowd: Version: 0.97-1ubuntu6
kernel: 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux

My machine is an IBM/Lenovo Thinkpad T60p (2007-93g), 2.16ghz Core Duo.

Only one CPU is controlled by powernowd upon wakeup.

If I restart the powernowd process the problem disappears.

[ian (ian6)]

I'm having the same problem with the latest (24/10/06) Kubuntu Edgy packages. Same versions as above. Laptop is a Toshiba Satellite A100-0FH, 1.6ghz Core Duo.

After suspend or hibernation, cpu0 uses the ondemand governor (good), cpu1 uses performance governor (not good). The fan 'sticks' on regardless of load, which may have something to do with the cpu running at 100%, I suppose. Restarting powernowd fixes the governor problem, I haven't tested to see if it fixes the fan too.

[John Clemens (clemej)]

If you're using powernowd, you should be using the userspace governor, not the ondemand one. powernowd will automatically set this when starting up, which is why restarting powernowd solves the problems you are all seeing.

When the system goes to sleep and comes back, apparently the kernel (or Ubuntu suspend scripts) aren't saving/restoring the right governor settings. This, to me, is a real bug, as suspend/restore is supposed to restore the system exactly how it was. powernowd has no way of knowing when a suspend happened, nor should it.

I can try and work around this in powernowd by periodically polling the scaling_governor file and resetting it to userspace if someone changes it out from under us. But I know of use cases where that would break other people (some people like to run powernowd all the time, and just "temporarily disable it" by changing the governor to performance for a while, and then change it back to userspace and powernowd just works again, all without restarting powernowd. )

my guess is, if you run powernowd with the -d -vv options by hand and then suspend/resume, you'll see that it's actually chugging along as normal, trying to control both cpus, but it speed change requests are ignored by the fact the system is using the wrong governor after suspend.

john.c (powernowd author, and someone who just noticed this on his company's macbook pro core duo running edgy)

[John Clemens (clemej)]

Actually, I'm wrong, it looks like edgy has changed to using the 'ondemand ' governor by default instead of the actual powernowd daemon. So my daemon isn't even running anymore.

Still the governor isn't getting restored correctly on both CPUs. this is a kernel and/or ubuntu script problem. Not a powernowd problem, unfortunately, so I can't help.

john.c

[Stefan Skotte (screemo)]

Ok John, thanks for your time :)

I will go on and see what else I dig up on this issue in the kernel/ubuntu scripts !

[Simon Law (sfllaw)]

This appears to be a problem with the kernel not remembering governors outside of cpu0.

A workaround could be written for powernowd, but that doesn't sound like the best idea.

[Ralf Doering (rdoering)]

A simple workaround for those actually using powernowd could be a script in /etc/acpi/resume.d, which calls something like "invoke-rc.d --quiet powernowd restart"

[Tim Rosenow (tim.r)]

I'm having this problem in Kubuntu Feisty on my HP Pavilion zv2040TX with a 1.7GHz Core 2 Duo

[Brian Murray (brian-murray)]

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

[Sergio Zanchetta (primes2h)]

The 18 month support period for Edgy Eft 6.10 has reached it's end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task.

Hardy Heron 8.04 was recently released. It would be helpful if you could test the new release and verify if this is still an issue - http://www.ubuntu.com/getubuntu/download . You should be able to test your bug using the LiveCD. Please let us know your results. Thanks.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Ralph Janke (txwikinger)]

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.