After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 367393 - CPU Frequency Scaling Monitor 2.16.0.1 second core monitor does not update after hibernation/resume
CPU Frequency Scaling Monitor 2.16.0.1 second core monitor does not update af...
Status: RESOLVED DUPLICATE of bug 356694
Product: gnome-applets
Classification: Other
Component: cpufreq
2.16.x
Other All
: Normal normal
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-10-30 03:43 UTC by Will Parker
Modified: 2006-11-20 11:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Will Parker 2006-10-30 03:43:44 UTC
Please describe the problem:
I find that when I resume2 the monitor applet does not report the status of my second core (cpu1) correctly indicating only that it is at "performance" and 100% 2.16G even though the actual status is correctly reported in the system.

spitfire cpu # cd cpu1/
spitfire cpu1 # ls
cache  cpufreq  online  topology
spitfire cpu1 # cd cpufreq/
spitfire cpufreq # ls
affected_cpus     ondemand                       scaling_driver    stats
cpuinfo_cur_freq  scaling_available_frequencies  scaling_governor
cpuinfo_max_freq  scaling_available_governors    scaling_max_freq
cpuinfo_min_freq  scaling_cur_freq               scaling_min_freq
spitfire cpufreq # cat scaling_cur_freq
1000000
spitfire cpufreq # cat scaling_governor
ondemand 


Steps to reproduce:
1. Have both cores displaying in deskbar
2. hibernate and resume
3. see the second core with the icon showing full speed and compare with system state.


Actual results:
 notice that after I suspend my Gnome (2.16 and 2.14) cpufreq panel applet :

CPU Frequency Scaling Monitor 2.16.0.1

only shows the correct freq and governor on CPU 0 after resuming from hibernation.

CPU1 sits at 100% and reports performance governor.

I can confirm that the CPU itself is Ondemand and at the level of CPU0 directly.

Code:

spitfire cpu # cd cpu1/
spitfire cpu1 # ls
cache  cpufreq  online  topology
spitfire cpu1 # cd cpufreq/
spitfire cpufreq # ls
affected_cpus     ondemand                       scaling_driver    stats
cpuinfo_cur_freq  scaling_available_frequencies  scaling_governor
cpuinfo_max_freq  scaling_available_governors    scaling_max_freq
cpuinfo_min_freq  scaling_cur_freq               scaling_min_freq
spitfire cpufreq # cat scaling_cur_freq
1000000
spitfire cpufreq # cat scaling_governor
ondemand
spitfire cpufreq #


and yet the applet shows 2.17G Performance.

If I restart the cpufreqd service with the init script or even cpufreqd and cpufrequtils the problem remains.

It is only resolved with a reboot or by removing and readding the CPU1 applet.

Expected results:
Correct indication of the second core state.

Does this happen every time?
yes

Other information:
Gentoo thread here:

http://forums.gentoo.org/viewtopic-t-510522-highlight-.html

no responses so far.
Comment 1 Raphael Slinckx 2006-11-20 11:32:50 UTC
I think this is a gnome-applets bug. Reassigning
Comment 2 Carlos Garcia Campos 2006-11-20 11:52:13 UTC
Thanks a lot for the bug report, it provides very useful information. 

This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 356694 ***