Frequency scaling doesn't work in current kernels

An additional note, although I use Lucid on amd64 arch, I've also checked with Maverick i386 livecd and that arch's 2.6.35 kernel also doesnt scale my CPU.

Still NOT fixed for 2.6.32-30 and 2.6.35-25!

This still means I can not update my Lucid kernel, nor upgrade to Maverick!

Someone else should have noticed this bug besides me..? I don't have THAT special machine to be the only one affected ;)

I have the same behavior on my Asus laptop, running 64 bit kubuntu.

from /proc/cpuinfo (booted in 2.6.32) it is a
model 23
Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz
stepping 10

When I boot to either 2.6.38-8 or 2.6.35-25 I'm stuck at 800MHz on both cores, and unable to set a minimum cpu speed above 800MHz.

When I boot to 2.6.32-24, it behaves as usual, running at 800MHz and going up to 2.534 GHz when needed.

This started when I upgraded from Maverick to Natty.

I have the same problem on my MSI laptop, with Ubuntu 10.10 x64

vendor_id : AuthenticAMD
cpu family : 15
model : 104
model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60

Frequency Scaling not working

Still not working with latest release kernels: 2.6.32-32 (Lucid), 2.6.35-28 (Maverick, backported to Lucid) and 2.6.38-8 (Natty)

@Litold: please check your CPU governor - maybe your machine purposely sets the lowest frequency when CPU unloaded... You may also recheck when the CPU is under high load.

Another thing I've remembered to mention - it doesn't matter if I boot a 32- or 64-bit system, with both scaling works fine with older kernels up to 2.6.32-24, and doesn't work at all with any newer kernel.

Please post which CPU you have and the contents of the following files - after trying to scale the frequency:

/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq (normally needs root privileges to read)
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Issue is solved by adding processor.ignore_ppc=1 to grub boot parameters

That kernel option works for me too!

I confirm, in both 2.6.32-32 and the latest 2.6.35 frequency scaling now works normally with that option. What does it do?

I wonder if that helps with Bug #786897 ...

fireandfuel, could you check?

@A.Kromic: It works for me, too.

Thank you very, very much, Litold.

I updated the BIOS of my Laptop to Version 1.20 (released only a few days ago) and the problem disappears ( and I removed the 'now useless' boot parameter). ^^

My problem is described here: http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling

The issue was running with 65W adapter and no battery. However, the laptop happily worked that way at full speed for a long time until the kernel version when that "protection measure" was added, and it worked fine all the time afterwards, first by using the old kernel, and then by using that kernel option. So I guess in this case the kernel protected me from nothing really; I suppose every other R6x/T6x/X6x Thinkpad with that problem can work that way with no ill effects.

I have the same problem with a Dell Inspiron 1420 under Precise. Except:
- I am using a 90W adapter, and I still only get 800 MHz
- The kernel option does not solve the problem for me :(

A.Kromic, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

Christopher: I have just commented on this issue a few days ago, how come it doesn't qualify as 'recent activity'?! Yes, this problem is still very much an issue.

If you wish, I could also execute the apport command. Is it OK or do you require the debug information from the original reporter?

David Nemeskey, as per https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported , if you would like a bug you have addressed, and you are not the original reporter, please file a new report via a terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]