[Lenovo ThinkCentre M55] CPU scaled back to very slow speed, cannot increase speed

Bug #962947 reported by Anton Piatek on 2012-03-23
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Linux
Incomplete
Medium
linux (Ubuntu)
Medium
Unassigned

Bug Description

It appears that my 1.86GHz Intel Core2 CPU is only running at 700Mhz. The attached files show (in /proc/cpu) that the cpu is actually a 1.86Ghz, but cpufreq only lets me set a maximum of 700mhz. I am running precise amd64 on a 3.2.0-20-generic kernel, though the same was seen linux-image-3.2.0-19-generic as well I believe.

The system is a Lenovo ThinkCentre 8810-91G, and the bios is the latest one available. The bios doesn't show any cpu limiting options or restrictions, and shows the cpus as the expected 1.86Mhz (though I think that is just model information rather than the current clock speed). I cannot see any overclocking options in the bios.

$cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 600 MHz - 700 MHz
  available frequency steps: 700 MHz, 600 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 600 MHz and 700 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz.
  cpufreq stats: 700 MHz:69.61%, 600 MHz:30.39% (3179)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 600 MHz - 700 MHz
  available frequency steps: 700 MHz, 600 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 600 MHz and 700 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 700 MHz.
  cpufreq stats: 700 MHz:59.66%, 600 MHz:40.34% (4168)

ACPI appears to be reporting a bios limit on the CPU, though I have no idea why.

$for i in /sys/devices/system/cpu/cpu0/cpufreq/*; do echo $i; sudo cat $i ; done
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus
0
/sys/devices/system/cpu/cpu0/cpufreq/bios_limit
700000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
700000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
700000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
600000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
10000
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus
0 1
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
700000 600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
700000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
700000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
<unsupported>

I can't recall if this was an issue on oneiric or not as I never looked at the cpufreq before. It may or may not be a new issue.

I'm not entirely sure if this is a kernel bug or something else (like ACPI), but am happy to try various other kernels to see if they help.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-20-generic 3.2.0-20.32
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
NonfreeKernelModules: nvidia
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: anton 4977 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Fri Mar 23 09:59:01 2012
HibernationDevice: RESUME=/dev/mapper/vg0-swap
InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100701)
MachineType: LENOVO 881091G
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-20-generic root=/dev/mapper/vg0-ubuntu ro quiet splash vt.handoff=7
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/12/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 2JKT49AUS
dmi.board.name: LENOVO
dmi.board.vendor: LENOVO
dmi.board.version: NONE
dmi.chassis.asset.tag: �������������������������
dmi.chassis.type: 3
dmi.chassis.vendor: LENOVO
dmi.chassis.version: NONE
dmi.modalias: dmi:bvnLENOVO:bvr2JKT49AUS:bd12/12/2008:svnLENOVO:pn881091G:pvrThinkCentreM55:rvnLENOVO:rnLENOVO:rvrNONE:cvnLENOVO:ct3:cvrNONE:
dmi.product.name: 881091G
dmi.product.version: ThinkCentre M55
dmi.sys.vendor: LENOVO

Anton Piatek (anton-piatek) wrote :
Brad Figg (brad-figg) on 2012-03-23
Changed in linux (Ubuntu):
status: New → Confirmed
Luis Henriques (henrix) wrote :

This seems to be an issue with the devfreq governors.

If you could also please 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 . 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. Please let us know your results.

Thanks in advance.

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Colin Ian King (colin-king) wrote :

I wonder if this is to do with a faulty BIOS frequency limit. To check this out can you try the following:

Edit /etc/default/grub (you need to do this using root privilege) and change

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash processor.ignore_ppc=1"

and then run:

sudo update-grub

and reboot. Maybe this will work around the issue.

Anton Piatek (anton-piatek) wrote :

Colin: Re #3, that seems to have made no difference. With the grub flag set, the cpu still has the same speed.

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

Anton Piatek (anton-piatek) wrote :

Assuming I actually got the correct upstream kernel, it doesn't seem to have solved the problem:

Let me know if there is another kernel you want me to try, or any other info to gather. Note that I can't run this kernel generally as dkms doesn't work so I don't get my nvidia modules.

anton@smeg:~$cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 600 MHz - 700 MHz
  available frequency steps: 700 MHz, 600 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 600 MHz and 700 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 700 MHz.
  cpufreq stats: 700 MHz:28.70%, 600 MHz:71.30% (650)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 600 MHz - 700 MHz
  available frequency steps: 700 MHz, 600 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 600 MHz and 700 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz.
  cpufreq stats: 700 MHz:18.00%, 600 MHz:82.00% (219)

anton@smeg:~$uname -a
Linux smeg.hursley.ibm.com 3.3.0-030300rc7-generic #201203101735 SMP Sat Mar 10 22:36:28 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

tags: removed: needs-upstream-testing
Changed in linux (Ubuntu):
status: Incomplete → New

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: New → Confirmed
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-20.33

Still exists in the latest kernel -21.34:

$apt-cache policy linux-image-`uname -r`
linux-image-3.2.0-21-generic:
  Installed: 3.2.0-21.34

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: bot-stop-nagging
removed: kernel-request-3.2.0-20.33
Jonas Jelten (jonas-jelten) wrote :

I've got the same problem on a Intel Core2 E6300 (http://ark.intel.com/products/27248/Intel-Core2-Duo-Processor-E6300-%282M-Cache-1_86-GHz-1066-MHz-FSB%29).

It's clocks are also limited to 600 and 700 Mhz.

System is Ubuntu 11.10 with it's most recent kernel, all other symptoms also match this bug report.

I would be happy if a solution came up, thanks for help.

Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.4kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). 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.

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.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc1-precise/

tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Anton Piatek (anton-piatek) wrote :

Bug still exists in mainline 3.4.rc2 kernel

anton@smeg:~$uname -a Linux smeg.hursley.ibm.com 3.4.0-030400rc2-generic #201204072235 SMP Sun Apr 8 02:36:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

anton@smeg:~$cpufreq-info cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009Report errors and bugs to <email address hidden>, please.analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 600 MHz - 700 MHz available frequency steps: 700 MHz, 600 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 700 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 700 MHz:45.14%, 600 MHz:54.86% (343)

tags: added: kernel-bug-exists-upstream
removed: needs-upstream-testing
Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
status: Incomplete → Triaged
Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Anton Piatek (anton-piatek) wrote :

Reverting back to a Ubuntu 3.0 kernel works fine!

$cat /proc/version_signature
Ubuntu 3.0.0-17.30-generic 3.0.22

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

Colin Ian King (colin-king) wrote :

@Anton, I'm finding this one hard to understand, the ACPI tables in your machine have the _PSS defined as:

        Name (_PSS, Package (0x02)
        {
            Package (0x06)
            {
                0x000002BC, // 700 MHz
                0x00007918,
                0x0000000A,
                0x0000000A,
                0x00000728,
                0x00000728
            },

            Package (0x06)
            {
                0x00000258, // 600 Mhz
                0x0000332C,
                0x0000000A,
                0x0000000A,
                0x0000061D,
                0x0000061D
            }
        })

So this explains the earlier limit of 600 or 700 Mhz CPU frequency. However, I don't understand why the 3.0.x kernel is now picking up faster settings for _PSS. Are you comparing the machine when running on AC or battery? Can you attach the ACPI tables to this bug now that you have higher CPU frequencies so I can just sanity check this.

do:

sudo apt-get install acpidump
sudo acpidump > acpidump.log

Thanks

Anton Piatek (anton-piatek) wrote :
Anton Piatek (anton-piatek) wrote :

Strangely, I accidentally booted a 3.2 kernel this morning and it is working at full speed. The machine is a desktop, so it is always on AC power.

anton@smeg:~$cat /proc/version_signature
Ubuntu 3.2.0-22.35-generic 3.2.14

anton@smeg:~$cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 1.87 GHz
  available frequency steps: 1.87 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.60 GHz and 1.87 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.87 GHz.
  cpufreq stats: 1.87 GHz:62.86%, 1.60 GHz:37.14% (658)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 1.87 GHz
  available frequency steps: 1.87 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.60 GHz and 1.87 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.87 GHz.
  cpufreq stats: 1.87 GHz:54.78%, 1.60 GHz:45.22% (540)

I am beginning to think that the BIOS or hardware is at fault.

Colin Ian King (colin-king) wrote :

Can you supply the ACPI dump when it gets stuck in a lower CPU frequency state too? It does seem curious, but the "faster" CPU configuration does not supply the _PSS in the tables, which is what was originally limiting the CPU speed.

Changed in linux:
status: Confirmed → Incomplete
Anton Piatek (anton-piatek) wrote :

acpidump for low cpu speed attached, it was generated from the ubuntu 3.2.0-23 kernel
$cat /proc/version_signature
Ubuntu 3.2.0-23.36-generic 3.2.14

Anton Piatek (anton-piatek) wrote :
Anton Piatek (anton-piatek) wrote :
Anton Piatek (anton-piatek) wrote :
Anton Piatek (anton-piatek) wrote :

I have just attached 3 more acpi dumps.

It appears that after updating a large number of packages yesterday, all 4 kernels I have installed run at 700mhz today.
3.2.0-22
3.2.0-23
3.0.0
3.4.0 mainline
all run at 700mhz. I am not sure the kernel itself can be the problem here

Attached is my dpkg log, hopefully someone can help me find another package which might influence the cpu scaling behaviour.

Anton Piatek (anton-piatek) wrote :

The plot thickens...
I turned of the computer for a few minutes this morning (it is normally always on), and when it came back up the CPU now shows a full speed range. Either it is something that a cold start reset in the bios, or perhaps something related to thermal protection trying to lock the max speed.
I had actually rebooted the box a few minutes before powering it off, and it was still running with a scaled back cpu speed, so it really doesn't look like it is related to the version of my kernel nor any packages.

Changed in linux:
status: Incomplete → In Progress
Dmitry Suloev (suloevdmitry) wrote :

Maybe it related to this bug https://bugzilla.kernel.org/show_bug.cgi?id=43284
I have same problem on my HP Compaq 6715b.

Changed in linux:
status: In Progress → Incomplete
Pablo Angulo (pablo-angulo) wrote :

Had a similar problem with intel atom (2 cores, 1,6GHz) in ubuntu 12.04:
 governor was ondemand, speed was always 800MHz (the lowest speed, and it felt way more slow than "twice as slow")

Upgraded to 12.10, the problem persisted.

Installed package cpufreqd (which was not present), and then the same governor "ondemand", keeps speed at 1.60Ghz, and I can work.

Want some data? Please ask

Carl Englund (englundc) wrote :

Tried the last solution, doesn't work for me.

root@LineaAlba:/etc# cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 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 (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:6,61%, 1.40 GHz:0,00%, 1.30 GHz:15,98%, 1.20 GHz:0,00%, 1.10 GHz:0,00%, 1000 MHz:0,00%, 900 MHz:0,00%, 800 MHz:77,40% (15)

Carl Englund (englundc) wrote :

I'm happy to report that "processor.ignore_ppc=1" seems to have fixed the problem. The output now looks like:

"cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.60 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:88,52%, 1.40 GHz:0,06%, 1.30 GHz:0,07%, 1.20 GHz:0,06%, 1.10 GHz:0,08%, 1000 MHz:0,09%, 900 MHz:0,06%, 800 MHz:11,06% (529)"

BTW this is a Samsung NC20 with the latest BIOS.

tags: added: latest-bios-2jkt49aus
tags: added: needs-upstream-testing
tags: added: regression-potential
tags: added: regression-release
removed: regression-potential

Anton Piatek, 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? If so, could you please test for this with the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Anton Piatek (anton-piatek) wrote :

I am now running saucy and the bug is still seen there
        current policy: frequency should be within 600 MHz and 700 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.

I will try a mainline kernel when I get time, but all the other mainline kernels I have tried in the past have this issue, and the upstream bug nobody seems to care about fixing either, so im pretty sure it will still be there.

Linux smeg 3.11.0-11-generic #17-Ubuntu SMP Tue Oct 1 19:42:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

tags: added: saucy
summary: - CPU scaled back to very slow speed, cannot increase speed
+ [Lenovo ThinkCentre M55] CPU scaled back to very slow speed, cannot
+ increase speed
To post a comment you must log in.