[hardy] Regression: powernowd no longer works with some chipsets

[Hanno Stock (hefe_bia)]

Binary package hint: powernowd

Description: Ubuntu 8.04
Release: 8.04
powernowd:
  Installiert:0.97-2ubuntu4

Updated description:

Powernowd (the package) does not work with chipsets where the ondemand governor fails. This is because now the powernowd init script only actually loads powernowd (the daemon) if the ondemand governor is not present.

Also gnome-power-manager now conflicts with powernowd as it also enables the ondemand governor by default.

Original description of the bug:

In gutsy I added cpufreq-nforce2 to my modules list and then powernowd nicely scaled the frequency on my Athlon XP 2400+. Now I upgraded to hardy and frequency scaling does no longer work.

However if I do the following, it works again (until next reboot):

sudo /etc/init.d/powernowd stop
sudo powernowd -q

If I do an 'sudo /etc/init.d/powernowd start' when powernowd is not running I get the following message in /var/log/messages:

"Apr 28 20:10:29 HANNO kernel: [10637.446135] ondemand governor failed, too long transition latency of HW, fallback to performance governor"

It seems that the init script loads the ondemand governor instead of userspace governor. How can I prevent this from happening?

[Hanno Stock (hefe_bia) (hanno-stock)]

I think I found a solution...

[Hanno Stock (hefe_bia) (hanno-stock)]

Here is a debdiff that fixes the above issue by testing whether the ondemand governor has really been loaded and else switching back to powernowd.

Please test on a system where ondemand would usually work, since I don't own such a system and therefore cannot test this setup.

[Hanno Stock (hefe_bia) (hanno-stock)]

Subscribing ubuntu-main-sponsors, since I'm not sure whether this is worth a SRU.
But I think this should be fixed in 8.04.1.

[Daniel Holbach (dholbach)]

Evan: can you please take a look at it?

[Sébastien Valette (sebastien-valette)]

Similar problem here, but Hanno's solution does not work:

$ sudo powernowd -q
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies: No such file or directory

[Hanno Stock (hefe_bia) (hanno-stock)]

> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies: No such file or directory

I get the error message mentioned above, too. But powernowd works regardless of this message. Could you please verify via the cpu speed applet (don't know the correct english name) that it is actually NOT working?

However even with my patch I still have some issues. CPU throttling seems to randomly stop working after the computer has run for a while. I'll try to debug the issue further.

[Evan (ev)]

Hanno, great work so far. Let me know via a comment on this bug when you've got an updated debdiff, should you fix the other issues, and I'll sponsor the upload.

[Sébastien Valette (sebastien-valette)]

>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies: No such file or directory

>I get the error message mentioned above, too. But powernowd works regardless of this message. Could you please verify via >the cpu speed applet (don't know the correct english name) that it is actually NOT working?

I checked it, and whenever I select Ondemand governor with the applet, it does not work. Instead, the applet switches to performance mode.

One side note : with Gutsy, I had to install powernowd, which removes cpufreq. This operation made ondemand governor work. I did the same with Hardy. Am I correct?

[Hanno Stock (hefe_bia) (hanno-stock)]

> I checked it, and whenever I select Ondemand governor with the applet, it does not work. Instead, the applet switches to performance mode.

Yes, that's right. The ondemand governor does not work with the nforce2 driver. Actually, when ondemand is used, powernowd (the daemon) is not used at all. The correct governor for powernowd is "userspace".

When you try to activate ondemand with the nforce2 driver it will switch to performance mode because of the error mentioned in my original report.

My patch should prevent the startup script from using the ondemand governor instead of powernowd on systems where ondemand is not supported.

However even with powernowd and the userspace governor activated, my system occasionally tries to switch back to the ondemand governor and therefore ends up with the performance governor because of the error mentioned above.

I have not yet figured out whether this is a problem with Ubuntu or powernowd. I'd appreciate any suggestions on how to debug this further.

[Hanno Stock (hefe_bia) (hanno-stock)]

My results so far:

I suspect the gnome-power-manager of changing the cpufreq governor.
I had the ac power cpufreq governor setting set to "nothing", while another user had it set to "ondemand". The change of cpufreq governor seemed related to the other user using the computer.

I have now set the cpufreq governor setting to "nothing" in the mandatory gconf preferences. I'll monitor whether the problem still exists.

If not this would mean there is a conflict between powernowd and gnome-power-manager. The powernowd package might have to set the mandatory settings mentioned above (and remove them when uninstalled...)

[Hanno Stock (hefe_bia) (hanno-stock)]

Update:
From syslog:
May 9 13:26:21 HANNO kernel: [ 3355.797659] ondemand governor failed, too long transition latency of HW, fallback to performance governor

Finger:
Login Name Tty Idle Login Time Office Office Phone
xxx xxx tty9 18 May 9 13:26 (:20)
xxx xxx tty7 May 9 12:04 (:0)

User #1 is the user with the "ondemand" gconf setting.

[Hanno Stock (hefe_bia) (hanno-stock)]

Here is an updated debdiff:

* In the init script I changed the code so that it specifically checks for the nforce2 driver. This makes it less generic (in case other drivers have a similar issue), but more reliable against timing issues.
* In post{inst,rm} I added code that installs mandatory gconf settings for gnome-power-manager IF it is installed. This disables the cpufreq functionality of gnome-power-manager. I thinks this is desired if people install powernowd.

However this adds a dependency on gconf2.

These changes solve all the issues I had.

[Joel Oliver (joelol75)]

I can report the same problem. I used to cat /proc/sys/cpuinfo and see 1000MHz on both cores unless I ran burnK7... Then it would jump to 2200 like it was supposed to. Setting in gnome to "Based on processor load" is the same as "Always maximum speed"

Setting it at "Max power saving" keeps it at 1000 but I will have to stay there until this problem is fixed as this computer is lightly loaded most of the time and on 24/7(I would love to try the debdiff, but not sure where and how to apply it (??/etc/init.d/powernowd???) I have a Nforce2 board but I don't have the problems others state with:
>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies: No such file or directory

I have:
2200000 2000000 1800000 1000000
in there...

Let me know if I can help in any way.

[Joel Oliver (joelol75)]

Sorry, for some reason the important stuff was cut of the end of /var/log/dmesg and only shows up in "dmesg" itself.. (Is this normal?)

[Hanno Stock (hefe_bia) (hanno-stock)]

Joel,

it seems that your setup is not using the nforce2 cpufreq driver, but the powernow-k8 driver - which is correct, I think, since the Athlon64 X2 supports PowerNow. (My Athlon XP does not)

So I guess your problem is a different one with similar symptoms only. I noticed that I also have the message "Clocksource tsc unstable (delta = -272825285 ns)" in my syslog, but I don't know what it means (Maybe someone else can clarify this?)

However, I have published the modified powernowd package to my ppa: https://launchpad.net/~hanno-stock/+archive
You can try it and see whether it fixes your issues as well.

[Evan (ev)]

gconf is not present on Kubuntu machines. Can you remove the strict dependency on gconf and rework the patch to use type to check for the presence of gconftool-2 instead?

Thanks and sorry for being horrendously late in replying.

[Hanno Stock (hefe_bia) (hanno-stock)]

Here is an updated patch with the dependency on gconf removed.

Thanks for the input and also sorry for replying so late.

[Hanno Stock (hefe_bia) (hanno-stock)]

Here is a debdiff for intrepid.

[Dmitry Mityugov (dmitry-mityugov)]

Sorry, can't understand from this discussion if this patch was committed to 8.04.1 or not?

[Hanno Stock (hefe_bia) (hanno-stock)]

Dmitry,

sorry, this patch didn't make it into 8.04.1.

[LizardMan (ubuntu-lizard)]

This problem isn't limited to nforce chipsets.

My Thinkpad A22p (1GHzP3 440BX chipset) laptop has the same problem. While running 7.10 the CPU freq throttling worked correctly without requiring any configuration changes. However, when I upgraded to 8.04 the CPU began to run at full speed (1000MHz vs. 700MHz) 100% of the time and dmesg showed multiple error messages "ondemand governor failed, too long transition latency of HW, fallback to performance governor".

This problem greatly reduces the laptop's battery life and causes the laptop to run hot.

Running the following commands (as root via sudo) returns the CPU freq control to normal operation.

sudo cpufreq-selector -g userspace
sudo /etc/init.d/powernowd stop
sudo powernowd -q

Note: this laptop does not support ACPI, only APM. Grub passes acpi=off to the kernel. If acpi=off isn't used several features of this laptop have problems.

[LizardMan (ubuntu-lizard)]

The command sequence in the comment above works, until the laptop changes power states due to disconnecting the AC adapter. All power state changes seem to trigger this problem, until the cpufreq-selector and powernowd -q commands are re-run.

[Hanno Stock (hefe_bia) (hanno-stock)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

LizardMan wrote:
> My Thinkpad A22p (1GHzP3 440BX chipset) laptop has the same problem.
> While running 7.10 the CPU freq throttling worked correctly without
> requiring any configuration changes. However, when I upgraded to 8.04
> the CPU began to run at full speed (1000MHz vs. 700MHz) 100% of the time
> and dmesg showed multiple error messages "ondemand governor failed, too
> long transition latency of HW, fallback to performance governor".

This looks like exactly the same problem. Please give me the output of

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

and I'll add that chipset to the patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIder23WPYSBTZvX0RAl95AJ4tpmqpTAAbe2WXwwH7hxDU9D/0OACgkSJF
b3RiQQr4s3aUwfS6+8kS4X0=
=JLhs
-----END PGP SIGNATURE-----

[Daniel Gimpelevich (daniel-gimpelevich)]

You CANNOT use a blacklist for this! On PowerPC, there is a scaling driver that both supports and doesn't support ondemand, depending on the specific hardware. The ONLY correct solution is the first idea you had, but with a better patch. Combine the gconf stuff from your patch with the patch in Bug #229027, and you'll fix Bug #223812, Bug #229027, and Bug #229672 all in one fell swoop.

[LizardMan (ubuntu-lizard)]

Hanno Stock,

After a fresh system start "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" returns speedstep-smi.

Running /etc/init.d/powernowd stop; cpufreq-selector -g userspace; powernowd -q (as root) returns the laptop to 7.10 style CPU freq scaling (two steps 700/1000 MHz). It seems to work fine until a power state change occurs. Unplugging the AC adapter or plugging it in causes the CPU scaling to lock in 100% mode again.

7.10 simply worked without any special configuration. What changed to cause this?

[Hanno Stock (hefe_bia) (hanno-stock)]

Here's an updated debdiff for Hardy

[Hanno Stock (hefe_bia) (hanno-stock)]

Updated packages also under https://launchpad.net/~hanno-stock/+archive

Please try and report back.

[Hanno Stock (hefe_bia) (hanno-stock)]

LizardMan wrote:
> It seems to work fine until a power state
> change occurs. Unplugging the AC adapter or plugging it in causes the
> CPU scaling to lock in 100% mode again.

This is because gnome-power-manager kicks in and activates its profile
for AC power / battery mode and sets the governor back to ondemand
(which then fails) which is the default.

The debdiff here fixes this by setting a mandatory default to disabled,
which means that gnome-power-manager will not deal with cpu throttling.

[Daniel Gimpelevich (daniel-gimpelevich)]

I installed the package in your PPA, and it crashed the system badly; I'm not sure why. I had to boot to recovery mode and reinstall the package.

Also, I think the gnome-power-manager package should be changed to default to "nothing" instead, because then, it would still be OK to install after powernowd, and the lack of the selection in the GUI won't be as big an issue. Bug 93404 is also related to that, IMO.

[Hanno Stock (hefe_bia) (hanno-stock)]

Daniel Gimpelevich schrieb:
> I installed the package in your PPA, and it crashed the system badly;
> I'm not sure why. I had to boot to recovery mode and reinstall the
> package.

I am sorry to hear that. However I have no clue, what would cause that,
since I have installed and uninstalled all versions of the package for
which I made a debdiff without problems.
Did you reinstall the PPA version or the official version?

> Also, I think the gnome-power-manager package should be changed to
> default to "nothing" instead, because then, it would still be OK to
> install after powernowd, [...]

I think that could be an option. But this way g-p-m would do nothing
even if powernowd is not installed.
Reviewing the postrm/-inst scripts I think it might not be at all
necessary to test for the presence of g-p-m. One could install the
mandatory defaults regardless of whether g-p-m is installed.
What HAS to be installed for this to work is gconftool-2.

Greetings,

Hanno

[Daniel Gimpelevich (daniel-gimpelevich)]

On Wed, 2008-07-16 at 22:12 +0000, Hanno Stock (hefe_bia) wrote:
> Daniel Gimpelevich schrieb:
> > I installed the package in your PPA, and it crashed the system badly;
> > I'm not sure why. I had to boot to recovery mode and reinstall the
> > package.
>
> I am sorry to hear that. However I have no clue, what would cause that,
> since I have installed and uninstalled all versions of the package for
> which I made a debdiff without problems.
> Did you reinstall the PPA version or the official version?

The PPA.

> > Also, I think the gnome-power-manager package should be changed to
> > default to "nothing" instead, because then, it would still be OK to
> > install after powernowd, [...]
>
> I think that could be an option. But this way g-p-m would do nothing
> even if powernowd is not installed.

Only by default; it could still be changed in gconf, which is how it
should be. It's academic anyway, since powernowd is part of the base
system install, rather than some optional add-on.

> Reviewing the postrm/-inst scripts I think it might not be at all
> necessary to test for the presence of g-p-m. One could install the
> mandatory defaults regardless of whether g-p-m is installed.
> What HAS to be installed for this to work is gconftool-2.

Again, this does not account for the case where gconftool-2 is installed
after powernowd.

[Hanno Stock (hefe_bia) (hanno-stock)]

Daniel Gimpelevich wrote:
>>> Also, I think the gnome-power-manager package should be changed to
>>> default to "nothing" instead, because then, it would still be OK to
>>> install after powernowd, [...]
>> I think that could be an option. But this way g-p-m would do nothing
>> even if powernowd is not installed.
>
> Only by default; it could still be changed in gconf, which is how it
> should be. It's academic anyway, since powernowd is part of the base
> system install, rather than some optional add-on.

I agree.

>> Reviewing the postrm/-inst scripts I think it might not be at all
>> necessary to test for the presence of g-p-m. [...]
>> What HAS to be installed for this to work is gconftool-2.
>
> Again, this does not account for the case where gconftool-2 is installed
> after powernowd.

Agreed, too.

I'd like somebody with some more experience to have a look at this. Also
g-p-m is flawed in a way that the settings of the last logged on user
wins. This might not be desirable on a multi-user-system.

So there are several options:

1) disable all power management in g-p-m.
2) disable power management in g-p-m by default, but let users change it.
3) disable power management in g-p-m only when powernowd is installed,
which is tricky to implement because of install order.

 affects ubuntu/gnome-power-manager

[Daniel Gimpelevich (daniel-gimpelevich)]

On Thu, 2008-07-17 at 12:46 +0000, Hanno Stock (hefe_bia) wrote:
> So there are several options:
>
> 1) disable all power management in g-p-m.
> 2) disable power management in g-p-m by default, but let users change
> it.
> 3) disable power management in g-p-m only when powernowd is installed,
> which is tricky to implement because of install order.

Option 3 is out of the question, and option 2 is still preferable to
option 1, especially in light of bug 93404.

[Hanno Stock (hefe_bia) (hanno-stock)]

Daniel Gimpelevich schrieb:
> On Thu, 2008-07-17 at 12:46 +0000, Hanno Stock (hefe_bia) wrote:
>> So there are several options:
>>
>> 1) disable all power management in g-p-m.
>> 2) disable power management in g-p-m by default, but let users change
>> it.
>> 3) disable power management in g-p-m only when powernowd is installed,
>> which is tricky to implement because of install order.
>
> Option 3 is out of the question, and option 2 is still preferable to
> option 1, especially in light of bug 93404.

(with "all power management" I meant "...related to the CPU" of course.)

Regarding bug 93404: IF the user would change the governor in g-p-m this
would deactivate powernowd, which would - if the conservative governor
doesn't work with the chipset - deactivate cpu throttling all together.
It is also possible to configure powernowd to act more like the
conservative governor.
But these are really two different things and making it all user
configurable without the several methods (powernowd and g-p-m / cpufreq)
conflicting is beyond bug fixing, IMHO.
I think this would be worth a spec ("clean up the cpu throttling mess"
or something alike ;) ).

The original intention of this bug report and discussion was to fix a
regression. This means: Make powernowd work as it did before.

I'd really prefer to stall this discussion until someone with more
experience and maybe knowledge about future plans for power management
takes a look at it.

[gatopeich (gatoguan-os)]

First thing, the mere length of this discussion for such a simple (and well described!) issue is dismaying. What's going on here? I guess it is just too easy to add an opinion...

Now, how come "powernowd" init script tries to run "ondemand" INSTEAD of "powernowd"? THIS IS THE ISSUE. I don't really want powernowd, I DON'T moinstall it in the first place...

Excuse the capitals, but I thought this discussion needs some clarity.

We just need to fix powernowd init script by removing every reference to "ondemand", actually to every other scaling governor which powernowd does NOT use. Let some ondemand lover go and write an ondemand package, instead of messing this one.

In other words, we want an init script that does this:

1.- Load "userspace" governor if necessary, as it is the one REQUIRED by powernowd (just read the README).

2.- Run "powernowd" daemon.

It can't be as complicated as the current script appears. I mean the current two-script system... Who was the genious around?

Now this is the script as I think it should be: simple and direct. And working!

Regards,
gatopeich.-

[fig_wright (fig-wright)]

I hit this bug after upgrading an IBM Thinkpad T22, and I can confirm that gatopeich's fixed /etc/init.d/powernowd file appears to have fixed it.

[Sébastien Valette (sebastien-valette)]

I also confirm that gatopeich's version of the powernowd script works for me also.

A small secondary effect is that the gnome cpufreq-applet does not allow to change the governor. Instead of proposing powersave, performance and so on..., it only shows "performance" which actually throttles the frequency depending on cpu load. Anyway, thanks!

[Ted Gould (ted)]

Marking as invalid for gnome-power-manager. This doesn't seem to be related to gnome-power-manager.

[Gerard Lledo (glledo)]

This bug is also reproducible on my ibook: The /etc/init.d/powernowd script exits gracefully thinking that the ondemand govenrnor has been loaded when it actually failed.

I "fixed" the script by not checking the ondemand stuff and just running powernowd.

[Steve Langasek (vorlon)]

gatopeich's proposed fix is incorrect. The powernowd package in Ubuntu implements Ubuntu's default power management policy, which /deliberately/ does not use powernowd+cpufreq_userspace if a better governor (ondemand) is available. So that init script would be a definite regression in another direction.

Hanno, your latest patch looks correct to me, except that now g-p-m no longer touches the governor settings and therefore there's no reason to mess with gconftool-2 in the maintainer scripts. Could you provide an updated fix that drops these changes?

I think we ought to also fix the package's description, since it's wildly inaccurate in Ubuntu, if you happen to be inclined to look at that - otherwise I'm happy to fix that myself.

[gatopeich (gatoguan-os)]

I see. According to you...

* The fix is wrong (essentially because it makes the package do what description says).

* Package description is wrong (apparently in order to support your previous assertion).

* Package name is wrong too, it should be named "anything-is-better-than-powernowd".

* Original Debian package must be wrong also. They should be fixing it to accomodate your more accurate idea of right and wrong.

What you are proposing is hijacking "powernowd" package for a purpose which would be better acomplished in other ways.

(My excuses go to the list readers if I am overextending with this strange issue.)

[Steve Langasek (vorlon)]

> What you are proposing is hijacking "powernowd" package for a purpose which would be better acomplished in other ways.

No, I'm informing you that this is *already* the purpose of the package in Ubuntu. And ondemand *is* better than powernowd (see what upstream kernel power management developers have to say about this), so we need a solution that uses powernowd only as a fallback.

[Hanno Stock (hefe_bia) (hanno-stock)]

Here is the updated debdiff for Jaunty.

I removed the g-p-m stuff and updated the package description. Should apply to intrepid package also, since it is the same version.

Gatopeich: While I agree that it is somewhat misleading to hijack the powernowd package, changing that is beyond the scope of this bug report. I guess a blueprint might be better suited for a bigger change in how cpu frequency scaling mechanisms are selected. You'd have to introduce a meta-package or some other kind of high level cpu frequency scaling package so it would install or activate the needed mechanism (powernowd or ondemand governor), depending on what hardware is in use. (After all it is supposed to work out of the box without user intervention for every hardware that supports it.)

[Launchpad Janitor (janitor)]

This bug was fixed in the package powernowd - 1.00-1ubuntu3

---------------
powernowd (1.00-1ubuntu3) jaunty; urgency=low

  * debian/init.d: Don't use ondemand governor if it is not working
    for the particular hardware. Thanks to Daniel Gimpelevich for the
    improved patch. (LP: #223812, #229027)
  * debian/control: Changed package description to better match
    what the package is doing in Ubuntu. (Using powernowd only as
    a fallback.)

 -- Hanno Stock <email address hidden> Mon, 01 Dec 2008 14:49:27 +0100