cpu frequency scaling monitor does not change frequency in Ubuntu Jaunty (9.04) alpha 5 on Core 2 system

[jasonq]

By default my 2.2 GHz system goes to 800MHz. I cannot change it to the full 2.2 GHz by setting the cpus to "performance". This is a regression as it worked in 8.10 and 8.04.

I am using the PC (Intel x86) desktop CD (that is, jaunty-desktop-i386.iso). It includes version 2.25.91 of the CPU Freuqency Scaling Monitor.

Here is /proc/cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm const
ant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 4388.54
clflush size : 64
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm const
ant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 4389.01
clflush size : 64
power management:

[Pedro Villavicencio (pedro)]

Which application are you using for changing that? could you take an screenshot of it? does the command line tools works fine?

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!

[jasonq (jason-quinn)]

Why do the bugs at launchpad get closed so quickly? Bugs do not rot. I didn't even realize there was activity on the bug and 30 days isn't all that much time to respond anyway.

I also don't understand why this bug was being closed because I did post what appears to be the proper information (Before I submitted my bug, I even found other bugs with comments saying what I posted is the information that is needed). The followup question doesn't even make much sense: 1) I said which program, the "cpu frequency scaling monitor" and 2) There's nothing to take a screenshot of that illuminates anything. If you don't know what the cpu scaling monitor is, how can you decide the importance of the bug is low?

[Sebastien Bacher (seb128)]

bugs get closed when they don't are good quality enough because there is some ten thousand open right now and a small team to work on those and keeping thousand of bad quality bugs open should makes work hardy for everybody, you can reopen a closed by when adding informations as stated before

[Sebastien Bacher (seb128)]

some extra notes:
- the bug is low for ubuntu because that's only an applet and not a core feature for most users
- similar issues have been fixed in jaunty
- your bug description is not clear, "doesn't work" is not useful, do you get an error, does it just ignore your action, does it do the change and revert it, can you give details?

[jasonq (jason-quinn)]

There's no error from the applet. There's nothing worth taking a screen shot. It applet just simply doesn't change the frequency. If you need more information, how about asking "Could you post the output of the ______ file after trying to switch the frequency?" or some other question that helps get the bug diagnosed instead of blaming the reporter. It's insulting to keep saying the bug report is poor when I already explained why it is not.

The devs at launchpad seem to fling around "closing this bug report because it lacks the information" even when the "lacks information part" is false. This policy alienates reporters. Instead of blaming bug reporters by saying the bug report is poor, the close message should be, "We are closing the bug because we have too few people and too many open bugs." That's still a bad policy but at least it's truthful and doesn't run the risk of false accusing someone of poor submissions.

A few points:
1) Bugs do not rot. If it's policy to close them early, it's a bad one.
2) Even a poorly reported bug can evolve into a good submission with time.
3) Users will provide missing information if you ask.
4) They will be offended if you call their submissions poor.
5) They will be really offended if the submission is not poor but people keep saying so like Chatty-Kathy dolls.
6) Bug reporters might end up quitting their submissions.

[Sebastien Bacher (seb128)]

there is just a way higher of bugs than of people working on those so there is no lack of bugs there and either we let the number and system get out of control and not usuable or we do quite active closing, the second option is the one used right now, it might not be perfect but that's what we can do right now

[Sebastien Bacher (seb128)]

"way higher number of bugs than ..."

[Sebastien Bacher (seb128)]

ok, the comment had typo and didn't make sense let's summarize clearly:

* there is lot of open bugs
* there is not so many people working on those
* having thousand of bugs and an outgoing count makes harder to find what to work on
* one way to get the list workable is to close actively bugs which lack details to be useful, there is enough detailed bugs to keep everybody busy for years so those will probably not be worked anyway
* usually bug reporter do ask required details, they might ask non pertinant replies, you can reopen or say that the comment doesn't make sense in such case
* the bug has been closed because it was incomplete and you didn't comment, with infinite ressources we could investigate such bugs but in the current situation if the reporter cares he,she should change it back to new

[JrBenito (jrbenito)]

I really can't agree to close this ticket. The gnome applet worked in past release and now it does not do a complete job as before.

I use AMD64 since 7.10 and use this application to change frequency of my AMD64 since 8.04 with no problem. I just updated to Jaunty and had some "good" surprises like a simple applet not responding to mouse clicks as before.

I know this will probably be closed again but no one can say I didn't try. Am I right?

Steps to reproduce:

-Use a processor with frequency scaling support (AMD64 and many others do)
-Install the cpu frequency scaling monitor applet on Gnome
-Click (left click) on applet

Expected results:

-> A menu with available frequencies and radio buttons to choice should appear
-> In the same menu a list of governors (like ondemand, performance, etc) should be available too

Actual results:

-> No menu or applet response is seen.

User impact:

-> The applet is almost useless, it still shows the actual frequency but did not change it.

If you need logs or anything else just tell me what you need. I will be very glad to help on the resolution.

Thanks and regards,

[Eric Brasseur (eric-brasseur-gmail)]

The problem is not with the Gnome frequency scaling applet. I used the cpufreq-selector command and it doesn't change the frequency either. I managed to get some reaction yet, by switching the ACPI daemon and related on and off quickly. Then, sometimes, for a few seconds, the frequency will decrease as was requested. Then it will rise back to maximum a few seconds later.

I monitored the frequency change with this dumb loop, that shows a time increase to perform the inner loop:

  while : ; do time { for (( b=0 ; b<10000 ; b++ )) ; do b=$b ; done } ; echo $a ; done

Just in case, I removed the Gnome applet... this didn't change anything to the problem.

By the way, the cpufreq-selector takes seconds to react. And doesn't change the frequency.

To me this is a major bug:

- My battery autonomy has decreased below what I need to do my job.

- I'm working in libraries. The fan switching on and off to cool the highclocked CPU is disturbing for me and for people around me. I'm writing this comment in the local cafeteria because I don't dare go to the library with this faulty laptop.

- My CPU radiator is accumulating dust.

I'm using a HP dv6000 laptop with Intel processor; dv6415eb to be precise.

[Eric Brasseur (eric-brasseur-gmail)]

I may have done a mistake somewhere but following the standard procedure to compile a custom kernel and dutifully copying /boot/config-2.6.28-11-generic to /usr/src/linux-source-2.6.28/.config I get qconf telling me that the kernel frequency has been locked to the maximum frequency and cannot be tuned (CPU_FREQ_DEFAULT_GOV_PERFORMANCE). Snapshot attached.

[Eric Brasseur (eric-brasseur-gmail)]

Well that was indeed the problem. Once the custom kernel was running, with the CPU frequency throttling simply and basically turned on, there was no more problem. The low frequency and power saving governors ran perfectly.

On the other hand I had no more Wi-Fi. 'Going to try to solve that one now.

[Eric Brasseur (eric-brasseur-gmail)]

There was no obvious graphical way to have the Wi-Fi driver reinstalled for the custom compiled kernel but commenting away the b43 module and its friends in the blacklist in /etc/modprobe.d/ and maybe installing the proprietary driver using b43-fwcutter did the job. So now I have both a silent and throttled down CPU and an exquisitely fine-tuned Wi-Fi connection. Happy.

[JrBenito (jrbenito)]

Hi Eric and all,

I have found the solution for this and other two bugs happened after upgrade from 8.04 -> 8.10 -> 9.04.

I did a "sudo polkit-gnome-authorization" and verified wrongly permission set to "frequency change" action. After grant right permissions the gnome applet can, now, change kernel frequency policy and change the frequency itself.

I noticed that many permissions I had in past release as normal user was revoked during the upgrade procedure. Even this being a secure way to conduct I think that permissions users already have shouldn't be revoke during upgrades. They should kept as is to avoid bugs like the gnome applet here, usb mount in bug #368959 and unlock buttons "locked" like in bug #242435. They could be avoided if old permissions was kept in the system during upgrades. I always had permission to mount my USB drives and since upgrade to 9.04 I could no use any external drive without mount by hand as root. (my with is angry until now with me :(

Eric, please, I think you should close this bug and let the "steps for solution" well documented because I don 't think it would be possible to correct permissions that were lost in the upgrade by using another upgrade. I just hope that 9.10 do not remove permissions again.

Thanks and regards.
Benito.

[Eric Brasseur (eric-brasseur-gmail)]

Hello Benito,

It's up to me to close the bug report?! I'll do that immediately.

Since a while the kernel updates for the 9.04 are compiled with the correct configuration regarding CPU frequency scaling so I stopped using my custom compiled kernel.

Sincerely.
Eric