Minimum and maximum cpu frequency are equal

[Atanas Atanasov]

I just noticed my laptop stared working considerably slower. I am using an updated 13.04, though the issue did not start right after the upgrade. After tracking down the issue I noticed that both processors operate at 800 MHz instead of the maximum 1800 MHz. Irrespective of the load, the frequency remains 800. Here are some stats:

    $ cpufreq-info
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to <email address hidden>, please.
    analyzing CPU 0:
      driver: powernow-k8
      CPUs which run at the same hardware frequency: 0 1
      CPUs which need to have their frequency coordinated by software: 0 1
      maximum transition latency: 109 us.
      hardware limits: 800 MHz - 1.80 GHz
      available frequency steps: 1.80 GHz, 1.60 GHz, 800 MHz
      available cpufreq governors: conservative, ondemand, userspace, powersave, performance
      current policy: frequency should be within 800 MHz and 800 MHz.
                      The governor "performance" may decide which speed to use
                      within this range.
      current CPU frequency is 800 MHz.
      cpufreq stats: 1.80 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:100.00%
    analyzing CPU 1:
      driver: powernow-k8
      CPUs which run at the same hardware frequency: 0 1
      CPUs which need to have their frequency coordinated by software: 0 1
      maximum transition latency: 109 us.
      hardware limits: 800 MHz - 1.80 GHz
      available frequency steps: 1.80 GHz, 1.60 GHz, 800 MHz
      available cpufreq governors: conservative, ondemand, userspace, powersave, performance
      current policy: frequency should be within 800 MHz and 800 MHz.
                      The governor "performance" may decide which speed to use
                      within this range.
      current CPU frequency is 800 MHz.
      cpufreq stats: 1.80 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:100.00%

Note the "current policy" says the frequency is between 800 and 800 irrespective of the hardware limits. The original governor was "ondemand", so I changed it to "performance" in order to see if that makes a difference which it didn't. No amount of invoking cpufreq-set or cpufreq-selector changes the frequency.

Looking around, I noticed several people reported similar issues in the past though no favorable answer exists. Any help would be greatly appreciated.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-19-generic 3.8.0-19.29
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: nasko 2398 F.... pulseaudio
CurrentDmesg:
 [ 39.683389] vboxdrv: fAsync=1 offMin=0x10104a4 offMax=0x10104a4
 [ 39.683848] vboxdrv: TSC mode is 'asynchronous', kernel timer mode is 'normal'.
 [ 39.683860] vboxdrv: Successfully loaded version 4.2.10_Ubuntu (interface 0x001a0004).
 [ 39.985701] vboxpci: IOMMU not found (not registered)
 [ 42.446439] init: plymouth-stop pre-start process (1891) terminated with status 1
Date: Mon Apr 29 01:45:06 2013
HibernationDevice: RESUME=UUID=f31bb83c-fcb0-4ec5-81cc-40fee0d3d80f
InstallationDate: Installed on 2012-11-13 (166 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MachineType: Dell Inc. Inspiron 1721
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-19-generic root=UUID=f649c2c6-c308-4d41-a92c-f75a3aac68de ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-19-generic N/A
 linux-backports-modules-3.8.0-19-generic N/A
 linux-firmware 1.106
SourcePackage: linux
StagingDrivers: zram
UpgradeStatus: Upgraded to raring on 2013-04-26 (3 days ago)
dmi.bios.date: 05/16/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0RT951
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA00:bd05/16/2007:svnDellInc.:pnInspiron1721:pvr:rvnDellInc.:rn0RT951:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Inspiron 1721
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.9 kernel[0].

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'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-raring/

[Atanas Atanasov (thenasko)]

I tested it against the latest mainline kernel (3.9.0-999), and the issue remains.

[Francesco Gozzini (gozzini89)]

I have the same problem. My cpu Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz. When on battery max_freq is locked down to min_freq, which is 800MHz. I'm using a fully updated Ubuntu 13.04. The problem was not there right after a fresh installation and appeared after some upgrade during the previous days.

I noticed that the file /sys/devices/system/cpu/cpu0/cpufreq/bios_limit contains '2701000' on AC and '800000' on battery. Adding the boot parameter 'processor.ignore_ppc=1' apparently fixes the issue, i.e. the bios_limit is '2701000' even on battery and the governor can use the full frequency range: but unfortunately the system remains slow on battery, it's like the frequency is ramped up very lazily.

[Atanas Atanasov (thenasko)]

I didn't think of observing the relation between the problem and the battery. I unplugged my battery and the problem is stopped. After plugging it back, and updating I am no longer experiencing the problem. The current kernel I am running is 3.8.0-19-generic.

@Francesco: Could you run the test again?

[Francesco Gozzini (gozzini89)]

I have an HP notebook. For me the problem arises precisely when on battery. When on AC the system scales correctly, both with battery in or off its location; just pull off the AC charger and the max frequency locks down to 800MHz per preocessor, which actually is the minimum possible. So the issue is probably related to power management. A fast heuristic test: time 'google-chrome' - on AC: 0.559s; just pull of the AC charger: 1.495s

I'm with kernel 3.8.0-19-generic. I've tried with two different batteries, no luck with both.

@Atanas: the issue is solved for you both with AC and on battery? Or without AC charger connected do you still experience the problem?

[Atanas Atanasov (thenasko)]

@Francesco: You are absolutely right. I thought the issue was resolved when on battery, but it is not. When I pull the power cord, the interval becomes 800-800. I am sorry for the confusion.

[Jorgen Smith (jorgen-7)]

I'm experiencing what appears to be the same on my Lenovo X1 Carbon with the 3.8.0-21-generic kernel. I use TLP, and if I have the ondemand governor set for battery, it is stuck at 0.8ghz (or the minimum frequency) no matter how much I load it up. Thus performance gets quite slow.

Modifying /etc/default/tlp to use performance governor instead for battery is a workaround for now, or alternatively changing the minimum frequency at which it is stuck.

The "ondemand" service wasn't running before, but starting it made no difference to its ability to ramp up from the minimum frequency.

[Alan Pater (alan-pater)]

I fixed this on my laptop by:

1) Plugging into a higher quality AC wall socket. (I was connected via a long extension cord.)
2) Adding "processor.ignore_ppc=1" to kernel boot command line.

See here: http://www.woolie.co.uk/article/dell-laptop-stuck-800mhz-linux-fix/

[Atanas Atanasov (thenasko)]

I don't think the fact there may be a kernel parameter fix (2 above) makes this bug "invalid".

[Alan Pater (alan-pater)]

Atanas, it's a hardware problem, no? AC adapter is not providing enough current, according to the bios.

The operating system (kernel) is just doing what the bios is telling it to do.

The kernel parameter is only a hack to work around the hardware problem.

[Atanas Atanasov (thenasko)]

I see your point. I still feel there is room for improvement in the way the kernel handles such "low current" situations, though that may be a separate issue.

[Francesco Gozzini (gozzini89)]

Today I've just noticed that on my laptop the issue is gone: I removed 'processor.ignore_ppc=1' from the default grub command line and the hardware limits are set up correctly in the range 800 MHz - 2.70 GHz. Using latest kernel 3.8.0-26-generic. Anyway for me the problem showed on battery, so it was not related to AC power socket.

[David Dchtoo (y-david-q)]

For anyone that might have this problem: I finally noticed what was lagging my PC, probably for ages. Duh.
This solved it - either the kernel boot parameter to disable the BIOS imposed limit as above, or what is noted down here:

http://blog.patshead.com/2013/04/my-bios-is-limiting-my-cpu-clock-speed.html

(as root)
echo 1 > /sys/module/processor/parameters/ignore_ppc
(this will not persist)

It's on a Lenovo X220. My battery's in a poor shape + my charger cable is (poorly) DIY fixed, which are probably connected.