Description of problem: On my laptop (a Centrino 2.0GHz 533FSB) the CPU sits at 800MHz to start with, and will scale up and down as the load increases and decreases. If I click on the icon and select 2.0GHz from the list, then the CPU is shown as running at 2.0GHz and cat /proc/cpuinfo shows the CPU running at cpu MHz : 1995.231 Close enough. If I then click on the 800MHz option (the lowest setting) the CPU stays at 2.0GHz. If then run something CPU intensive and stop it (glxgears) the CPU then scales back to 800MHz. Version-Release number of selected component (if applicable): gnome-applets-2.11.1-2 How reproducible: Always Steps to Reproduce: See above. Actual results: CPU doesn't scale back down. Expected results: I would expect the CPU to go back to running at 800Mhz
Same thing here, there's no way to lower frequencies once they've been pushed up : processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3500+ stepping : 0 cpu MHz : 2211.357 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 4427.40 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc gnome-applets-2.12.1-2 kernel-2.6.14-1.1632_FC5
Hello, I think, one should need more information to find out what happens. Could you please post the content of /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor or (better) the output of cpufreq-info As far as I could see in my (older) FC4 version, the applet sets the frequency correctly and the governor sets it back after a short time. So maybe they are interfering in some way. I think, the gnome-cpufreq-applet should set the givernor to userspace, if the user changes the frequency. (and it should have some kind of way to set it back to the governor before)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor userspace No cpufreq-info on this system
ditto for me: [rodd@localhost ~]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor userspace No cpufreq-info on this system
Hi there, it seems to me, that one of the patches applied by redhat in the rpm build process is wrong. If you install the src.rpm of gnome-applets, you can find /usr/src/redhat/SOURCES/gnome-applets-2.11.1-cpufreq.patch which contains the following: - command = g_strdup_printf ("%s -f %d", path, freq); + command = g_strdup_printf ("/usr/bin/cpufreq-selector -f %d", path, freq); As you can see, the function g_strdup_printf is called with three parameters, but the first one (format string) contains only one parameter to be substituted.) I can't figure out, what the result of this is and/or if it causes your problem - but this patch was not there in versions before 2.11.1 I have no laptop with rawhide around, so I neither check this nor create a new rpm without this line Regards, Ingo
I've just noticed this interetgin bit in /var/log/secure : - When asking for 2,2 GHz : Nov 12 16:05:19 rousalka userhelper[17254]: running '/usr/sbin/cpufreq-selector -f 6476944' with root privileges on behalf of 'nim' - When asking for 1 GHz Nov 12 16:06:32 rousalka userhelper[17268]: running '/usr/sbin/cpufreq-selector -f 6539776' with root privileges on behalf of 'nim' So it seems the root of the problem is the applet calling /usr/sbin/cpufreq-selector with bogus parameters I'll try the fix you proposed ASAP - needs to get my system back in bootable state first
Ok, I can confirm the obvious fix - command = g_strdup_printf ("%s -f %d", path, freq); + command = g_strdup_printf ("/usr/bin/cpufreq-selector -f %d", freq); fixes the the applet. So it's a bug in the Fedora patch, not in the upstream version -> promoting to FC5Blocker as the fix is known, and closing the upstream bug
Hi, Thanks guys for figuring this out. Fix should be in tomorrow's rawhide.