cannot change governor from command line

[Rolf Leggewie]

Binary package hint: gnome-applets

I am usually running Karmic XFCE. Trying to change the CPU frequency governor from the command line fails. Using the applet while in Gnome works. I can also switch to performance and powersave governor but none of the other that are available.

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance
$ time sudo cpufreq-selector -g ondemand

real 0m30.416s
user 0m0.016s
sys 0m0.008s
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

I get the following warning in /var/log/syslog: "Sep 18 21:51:07 X24 kernel: [11130.102375] ondemand governor failed, too long transition latency of HW, fallback to performance governor"

[Chris Coulson (chrisccoulson)]

Thank you for your bug report. That looks more like a kernel issue rather than an applet one though

[Rolf Leggewie (r0lf)]

If it's a kernel bug, then it's not Ubuntu-specific. The mainline kernel is no different.

[Chris Coulson (chrisccoulson)]

Please run:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "conservative" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "userspace" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

[Rolf Leggewie (r0lf)]

As I mentioned in our private chat, I have serious doubts this is a kernel bug. I can switch governors with the applet, but using the CLI fails.

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
$ echo "conservative" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
$ echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
$ echo "userspace" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
$ echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
$ echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

[Rolf Leggewie (r0lf)]

turns out, this is indeed a kernel bug after all. At least mainline kernel 2.6.28-02062810-generic works fine. So, it's a fairly recent regression. I'll disect in the next few days to find the latest working kernel.

[Matthias Sommer (sunny0815)]

Count me in, same here, cannot change CPU frequency on a 2.0 GHz P4.
I can switch manually to powersave, all other governors show the "too long transition latency..." mentioned above and fallback to performance.

[Rex Wheeler (rex-wheeler)]

I have a similar problem. I can't set the ondemand governer either through the command line or GUI since upgrading to Karmic. Here is the output of the above request from a boot to the previous kernel (it all works here):

tiger@seq:~$ uname -a
Linux seq 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC 2009 i686 GNU/Linux
tiger@seq:~$ echo "conservative" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
tiger@seq:~$ echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
tiger@seq:~$ echo "userspace" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
tiger@seq:~$ echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
tiger@seq:~$ echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Booting to kernel after Karmic upgrade (same machine):

tiger@seq:~$ uname -a
Linux seq 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux

tiger@seq:~$ echo "conservative" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tiger@seq:~$ echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tiger@seq:~$ echo "userspace" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
tiger@seq:~$ echo "powersave" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
tiger@seq:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
tiger@seq:~$ echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

It's a P4 Celeron:

tiger@seq:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.00GHz
stepping : 7
cpu MHz : 2000.000
cache size : 128 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 mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid
bogomips : 4029.71
clflush size : 64
power management:

I get these in syslog:

Oct 30 13:51:30 seq kernel: [ 934.785094] conservative governor failed, too long transition latency of HW, fallback to performance governor
Oct 30 13:51:30 seq kernel: [ 934.886535] ondemand governor failed, too long transition latency of HW, fallback to performance governor

[Rex Wheeler (rex-wheeler)]

One additional note: I can manually (with the GUI app) set my clock frequency to any of the supported frequencies (.25GHz -2GHz in .25GHz steps), I just can't set the ondemand governer to make it autoscale.

[Anno Loki (h-launchpad-panakos-co-uk)]

This has been deliverately broken in recent kernel as it's been deemed "too slow" for us to carry on using. If like me you disagree, you can reverse the change quite easily if you're building your own kernel/modules, I'll try and post these details to where I can find people who've hit the same problem and want to undo the change.

If you run:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
you will notice the latency is 10000001, which I thought looked highly suspicously like someone had hardcoded that number somewhere to be 1 more than a max number set somewhere where the ondemand/etc would work. You can find it in the file (assuming kernel sources are in /usr/src/linux) :

/usr/src/linux/arch/x86/kernel/cpu/cpufreq/p4-clockmod.c

If you search in that file for the number 10000001 in that file, decrease it by one to 10000000, and recompile the module (if you have p4-clockmod compiled as a module; if it's linked into the kernel you'll need to recompile the kernel and reboot).

I have found that changing the up_threshold of the ondemand governor from its default to 40 makes it ramp its speed up when I need it to, and stay there until it drops back down again. With my usage pattern it's not making these switches very often, so any delays in changing the speed are perfectly acceptable -to me-. To do this, simply:
echo 40 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

Hope there's someone out there this helps. Oh, and of course, yay for open source! We don't have to someone telling us we can't do something with our own computer cuz they don't think it's fast enough! :-)

[crackbaby (edwardsp)]

I'm glad to finally figure out why ondemand doesn't work.
That said, I'm disappointed to hear the outcome.

I, for one, hope the Ubuntu community decides to reverse this kernel decision

[Rolf Leggewie (r0lf)]

Anno, great find. Thanks for sharing. But, my situation does not fit your description.

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
4294967295

Did this change recently or is this something changed in Ubuntu?

[Rolf Leggewie (r0lf)]

today's mainline kernel does not have this problem anymore. It's fixed upstream.

next steps:
1) bisect to the upstream kernel that broke as well as the one that fixed this
2) recompile Lucid kernel to see if it's fixed there

[Rolf Leggewie (r0lf)]

This does indeed work in the Lucid kernel which as I was told runs straight in karmic without recompilation. Setting to fix released. If somebody figures out what it was exactly that fixed this and provides a minimal patch I guess that could be backported to the 2.6.31 kernel for inclusion in karmic.

[Anno Loki (h-launchpad-panakos-co-uk)]

FYI (I'm not sure how relevant this still is) but 4294967295 is as recognisable a number as 10000001 is: it's -1 on a 32bit processor, or 0xFFFFFFFF.

The 10000001 number in the kernel mod I use is assigned by
   policy->cpuinfo.transition_latency = 10000001;

A grep for other modules setting this:
   grep 'policy->cpuinfo.transition_latency' /usr/src/linux/arch/x86/kernel/cpu/cpufreq/*.c
reveals a bunch of modules, for the different CPUs, that set:
   policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;

CPUFREQ_ETERNAL can be found by:
   grep CPUFREQ_ETERNAL /usr/src/linux/include/* -R
       /usr/src/linux/include/linux/cpufreq.h:#define CPUFREQ_ETERNAL (-1)

So that is indeed the figure. To reenable kernel ondemand/conservative support for your proc, simply edit the module source for your cpu, search for transition_latency = CPUFREQ_ETERNAL and replace it with 10000000. Note of course that I have a different cpu, so you should consider such an action as 'experiemental'; if the ondemand/conservative gov switches too quickly and your proc can't handle it, your system might run v.slow or stand still, so boot up with the performance/userspace gov and switch over to test, rather than set ondemand/conservative as the default on-boot governor.

This is of course just an FYI if you have the problem resolved another way; I just found the replies as I just updated my kernel and couldn't remember which file I edited first time round, so came back here to find my own post :-)

[crackbaby (edwardsp)]

Rolf, is Anno's guidance enough to backport? This has been bugging me for a while

[Rolf Leggewie (r0lf)]

crackbaby, I don't know. But I think I did try once something along those lines and it did not fix the issue for me. Your best bet currently is to run the lucid kernel.

[crackbaby (edwardsp)]

I just upgraded to lucid and this is still a problem for me. I'm not sure if there is any change I have to make but it doesn't seem to work out of the box for me on lucid...

[Bassjunkie (mark-skrzypczyk)]

I believe I am also experiencing the same bug.
I started trying to get CPU scaling enabled on my HP DL380 G3 (2x Xeon 2.4Ghz HT) a couple of days back and wasn't having much luck using powernowd or the command line to manually set governer.

I ended up using cpufreqd as this at least seemed to allow scaling on one of the 2 CPU in the machine. I went back in and checked my dmesg and I'm getting the ondemand governor failed, too long transition latency of HW, fallback to performance governor error messages (mentioning both ondemand and conservative).

I'm using the p4-clockmod module for this and the output of cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency is also 10000001 as mentioned by Anno previously.

[FactTech (launchpad-facttechnologies)]

I'm seeing the same issue with the same apparent cause as Anno Loki explains in comment #9. Like her, I disagree with this change; I'm running Lucid on a Sony Vaio PCG-GRZ610 which is a tremendous power hog when the "ondemand" setting is not available. I had it running for years using ondemand under Hardy, and I don't understand why this functionality would be deliberately broken; this seems like a regression in Lucid, from my viewpoint.

Anno Loki, are you still out there? Any chance you can provide step-by-steps to modify and recompile the p4_clockmod module? I've never compiled a module before and would appreciate the guidance (as I'm sure many other users would).

[Doki (lkishalmi)]

Well you don't really need to recompile the module a simple binary hack could solve the problem. The basic idea is that 10000001 is 00989681 in hex and stored in p4-clockmod.ko as 81969800 a "simple" search for it and replace it with 80969800. So I did the following hack (far from being optimal):

1. cp /lib/modules/2.6.32-24-generic/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko p4-clockmod.ko.orig
2. xxd p4-clockmod.ko.orig p4-clockmod.ko.hex
3. vim p4-clockmod.ko.hex (search for 81 and check that it is followed by 96 98 00 in hexdump)
4. Replace the right 81 to 80
5. xdd -r p4-clockmod.ko.hex p4-clockmod.ko
6. sudo cp p4-clockmod.ko /lib/modules/2.6.32-24-generic/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko
7. sudo reboot

[Stormdawn (stormdawn)]

Changing to "ondemand" doesn't work for me, too. I'm using lucid with a P4 celeron 1,46GHz.

[Stormdawn (stormdawn)]

Ok, I finally tried out Doki's idea and it worked fine! :)

[Dan Kortschak (dan-kortschak)]

A binary hack is a silly way to have to fix something that should not have been broken.

If ondemand is too slow - make the default performance so the user can choose, rather than making ondemand work exactly the same way as performance. Honestly, what is the point of having two policies that do exactly the same thing and remove functionality that is obviously missed by users?

When will this regression be fixed?

[yossarian holmberg (ubuntu-yossman)]

throwing my two cents in; i agree 100% with #23 (dan k.) -- the CPU frequency scaling control capability and applet is one of my favorite things about linux and the ubuntu/GNOME desktop environment, and i attempt to enable it on every single machine i put ubuntu onto. i have personally witnessed the big difference it can make on some desktop systems i've deployed, in terms of how hot they run, and how much power they use, especially when online 24/7..

have the applet default to 'performance' mode if 'ondemand' is too slow, sure, but don't break 'ondemand' on purpose! do you really think the majority of your userbase is too ignorant to do two mouse clicks to change the setting themselves? and if so, why do you even still list 'ondemand' as a choice, if you're just going to leave it broken? the ubuntu desktop installation doesn't even put the CPU frequency scaling applet onto the panel by default, you have to put it there yourself. doesn't it stand to reason that if you put it there yourself, you could probably also figure out which of the automatic governor settings you're OK with using?

i would definitely appreciate having that choice back, and i can see there are still more people on forums asking about this. to the people who complain ondemand is too slow: put it in performance mode, leave it there, and be happy you have a choice about the matter, because right now some of us have lost our ability to choose to do otherwise, which isn't right.

final point: are we trying to be more environmentally friendly, or not? anything that reduces excess heat and power usage is good, in my opinion. ;-)

[yossarian holmberg (ubuntu-yossman)]

ps. powernowd gives me back the behaviour i was looking for from the 'ondemand' setting, for anyone who wants to try that, last machine i used this fix on was a toshiba C650D laptop with ubuntu 10.04.

[FactTech (launchpad-facttechnologies)]

I see this issue is marked as "fix released" and "nominated for karmic", but what happens next? Will this be corrected in Lucid?

[Rolf Leggewie (r0lf)]

FactTech, I don't think there will be any SRU updates for karmic. I tried with the lucid kernel and FWIW, the change from the command line works fine even though it takes quite a while to do so.

[Dert Hunter (derthunter)]

Doki (lkishalmi) solution works great for me. I`m impressed that i had to correct it on ubuntu 10.10 maybe on next release it comes fixed. I had to install cpufrequtils for the cpufreq indicator to work. Is not very fast but for an old celeron M notebook working as a router ondemand governator works very well.