GNOME Bugzilla – Bug 376612
Doesn't start up correctly with two CPUs
Last modified: 2007-05-08 10:57:54 UTC
I have two CPU-Frequency Applets (one for each CPU). Both applets should display the icon and the frequency. After adding and configuring both applets everything seemed to work. Then I logged off and logged in later. The applet for CPU0 seemed to work allright, but the applet for CPU1 was not displaying the text. In the properties everything seemed to be fine and after unchecking and rechecking the checkbox for the text, everything was the way I wanted it to be.
hmm, I think it's also fixed. Could you upgrade gnome-applets from cvs and try again, please? I have also two applets with icon and text, and I don't have this problem. Thanks for the bug report.
*** Bug 377570 has been marked as a duplicate of this bug. ***
I can confirm this bug in 2.16.1. I would upgrade from cvs to confirm it's fixed, if it's easy to do so. I suspect it's not though.
*** Bug 376615 has been marked as a duplicate of this bug. ***
Will we get the fix also for the stable version, please?
I thought this change: http://cvs.gnome.org/viewcvs/gnome-applets/cpufreq/src/cpufreq-applet.c?r1=1.23&r2=1.24&only_with_tag=gnome-2-16 fixed this bug, but Anders has confirmed it's still present in 2.16.1, so right now I don't know where is the problem. I can't reproduce it, but it would be great if someone with gnome-applets from cvs head could confirm that it's actually fixed in head.
Created attachment 80562 [details] [review] Patch to make second CPU display correctly after suspend/resume
I suspect this is much the same problem that I've been seeing. In my case, at least, it's actually linked to suspend/resume. During this process, all CPUs beyond the first are disabled. This causes the applet to be unable to get the policy, causing the timer callback cpufreq_monitor_libcpufreq_run() to return FALSE, thus in turn causing further updates not to occur (except those that are triggered as a result of a non-timer action such as changing the display style). I've attached a patch (against CVS head) that resolves it for this case by checking if the CPU exists, and returning TRUE, even if the policy could not be acquired. It's not especially pretty and I suppose would give slightly incorrect behaviour if someone actually disabled a CPU during normal operation (would anyone do that?) in that it would continue to display the last known speed, rather than indicating that it's disabled. But it works for me :) Note that if you're using gnome-power-manager, this fix seems to expose a bug in it where after suspend, the second CPU is using the wrong governor. Of course, this probably always used to happen but you couldn't see it because the cpufreq display wasn't working. I'll get to that next...
Thanks a lot for your comments, I understand the problem now :-) However the problem you are describing is not related to this bug, but to bug #356694. I've just committed a fix to svn trunk.
Aw, dammit :) I didn't find that other one when I was searching. I need to look harder next time. Incidentally, I unfairly besmirched gnome-power-manager - the problem I described is apparently a kernel bug.
Is this bug still reproducible for anybody with gnome 2.18? Thanks.
No, not reproducable with 2.18 anymore.