This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 164147 - CPU Frequency Scaling Monitor turns CPU up, but not down.
CPU Frequency Scaling Monitor turns CPU up, but not down.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-applets (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Mike McLean
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2005-07-25 08:05 EDT by Rodd Clarkson
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-14 13:32:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 320296 None None None Never

  None (edit)
Description Rodd Clarkson 2005-07-25 08:05:23 EDT
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
Comment 1 Nicolas Mailhot 2005-10-31 05:00:31 EST
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
Comment 2 Ingo Schaefer 2005-11-08 04:58:36 EST
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)

Comment 3 Nicolas Mailhot 2005-11-08 09:20:31 EST
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace

No cpufreq-info on this system
Comment 4 Rodd Clarkson 2005-11-08 18:25:29 EST
ditto for me:

[rodd@localhost ~]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace

No cpufreq-info on this system
Comment 5 Ingo Schaefer 2005-11-09 05:11:26 EST
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
Comment 6 Nicolas Mailhot 2005-11-12 10:06:24 EST
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
Comment 7 Nicolas Mailhot 2005-11-12 11:16:37 EST
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
Comment 8 Ray Strode [halfline] 2005-11-14 13:32:38 EST
Hi,

Thanks guys for figuring this out.  Fix should be in tomorrow's rawhide.

Note You need to log in before you can comment on or make changes to this bug.