Bug 43091

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 cpufreq@vger.kernel.org, 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)

3.0 works
3.2 works (according to ubuntu bug report)

3.4-rc2 fails, according to comment #2
How about 3.3?
How about the latest 3.4 (now -rc4)?

3.2 is odd actually. The following 3.2.0-22 kernel worked
anton@smeg:~$cat /proc/version_signature
Ubuntu 3.2.0-22.35-generic 3.2.14

But this 3.2.0.-23 kernel didn't work.
$cat /proc/version_signature
Ubuntu 3.2.0-23.36-generic 3.2.14

I am wondering if something else rather than the kernel is the cause, or is
part of the cause.

I will try a few more kernels and post here and the ubuntu bug what works and
what doesn't

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 ubuntu
3.2.0-23 ubuntu
3.0.0    ubuntu
3.4.0    mainline
all run at 700mhz. I am not sure the kernel itself can be the problem here. Is there anything else I should be looking at, or should I just close this bug report as not being a kernel bug?

I'm having the same problem but with a core i5 processor. Also reported a bug first to Ubuntu, you can find all the details there (/proc/cpuinfo, etc):
https://bugs.launchpad.net/bugs/987531

For me it works with the conservative governor but not with the ondemand governor. Should I report another bug?

please show the output from

grep . /sys/devices/system/cpu/cpu*/cpufreq/*

in particular, somebody could have scribbled on the max_freq.

Given that all the kernels fail, possibly some user-space package
has gone wrong.

$sudo grep . /sys/devices/system/cpu/cpu*/cpufreq/*
/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>
/sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/bios_limit:700000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:700000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:700000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:10000
/sys/devices/system/cpu/cpu1/cpufreq/related_cpus:0 1
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies:700000 600000 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:conservative ondemand userspace powersave performance 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:700000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported>

While running a 3.2.0-23.36-generic ubuntu kernel.

I am leaning towards some userspace package being the cause, as I have tried several kernels and all produce the same error after now. I have absolutely no idea what package, but hopefully my Ubuntu bug can track that down. Should I close this? Or is there anything else to try before assuming it is all userspace

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.

re: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit:700000

I think this means that the BIOS is telling your system
not to exceed 700 Mhz.

Are there any messages in dmesg when this happens,
say about thermal throttling due to over-heating.
(please attach full dmesg upon failure)

What do you see when you poke at the temperature
of the system?

Please show the output from 
grep . /sys/class/thermal/thermal*/*

and see if the temperature "temp" relates to success and failure.

Also, when you boot with processor.ignore_ppc=1, please attach
the output from

grep . /sys/devices/system/cpu/cpu0/cpufreq/*

finally, 
Please attach the output from acpidump
(collected in any configuration)

Created attachment 77501 [details]
sensors output

Created attachment 77511 [details]
dmesg output

Created attachment 77521 [details]
acpidump

Have just rebooted and got limited cpu. 

I cannot find the thermal sys entries you wanted, would they have been renamed?
$ls /sys/class/thermal/
cooling_device0  cooling_device1

$ls /sys/class/thermal/cooling_device*/ -l
/sys/class/thermal/cooling_device0/:
total 0
-rw-r--r-- 1 root root 4096 Aug 13 08:38 cur_state
lrwxrwxrwx 1 root root    0 Aug 13 08:38 device -> ../../../LNXSYSTM:00/LNXCPU:00
-r--r--r-- 1 root root 4096 Aug 13 08:38 max_state
drwxr-xr-x 2 root root    0 Aug 13 08:38 power
lrwxrwxrwx 1 root root    0 Aug 13 08:30 subsystem -> ../../../../class/thermal
-r--r--r-- 1 root root 4096 Aug 13 08:38 type
-rw-r--r-- 1 root root 4096 Aug 13 08:30 uevent

/sys/class/thermal/cooling_device1/:
total 0
-rw-r--r-- 1 root root 4096 Aug 13 08:38 cur_state
lrwxrwxrwx 1 root root    0 Aug 13 08:38 device -> ../../../LNXSYSTM:00/LNXCPU:01
-r--r--r-- 1 root root 4096 Aug 13 08:38 max_state
drwxr-xr-x 2 root root    0 Aug 13 08:38 power
lrwxrwxrwx 1 root root    0 Aug 13 08:30 subsystem -> ../../../../class/thermal
-r--r--r-- 1 root root 4096 Aug 13 08:38 type
-rw-r--r-- 1 root root 4096 Aug 13 08:30 ueven

Will reboot with the processor.ignore_ppc=1 and gather that data too

Created attachment 77531 [details]
dmesg with processor.ignore_ppc=1

Created attachment 77541 [details]
grep of cpufreq with processor.ignore_ppc=1

For the record, my kernel at this time is 3.2.0-29-generic Ubuntu
$ cat /proc/version_signature 
Ubuntu 3.2.0-29.46-generic 3.2.24

I'm not sure if I should be changing the state of this bug now that I have collected data.

I can't prove the temperature is the cause, but turning off the box for 10 minutes and then rebooting it appears to be a workaround to get back to a full speed cpu.

so processor.ignore_ppc does not help in your case, right?

correct

Just in case it helps, I had a similar problem with my Notebook (Toshiba Satellite Z830) and I "fixed" it by changing some BIOS option. Here is an article I wrote about it:
http://www.llucax.com.ar/blog/blog/post/-31ba9e5e

You might want to try messing around with the BIOS settings...

Hi Anton,

Does justincase's suggestion help for you?

ping ...

No, there are no BIOS options which appear to help.

The best I can figure out is something related to a thermal cutout, as rebooting often sees the issue continue, but powering off for a few minutes and letting the cpu cool seems to have the cpu come up at full speed.

It could even be a thermal limit built in to the bios, rather than the kernel, but that is pure speculation and I have no way of testing that hypothesis.

(In reply to comment #5)
> I'm having the same problem but with a core i5 processor. Also reported a bug
> first to Ubuntu, you can find all the details there (/proc/cpuinfo, etc):
> https://bugs.launchpad.net/bugs/987531
> 
> For me it works with the conservative governor but not with the ondemand
> governor. Should I report another bug?

please file a new bug report if the problem still exists in the latest kernel.

Anton,
First, please find a kernel that the problem does not exist. or else I'll remove the regression flag.
Second, please attach the output of " grep . /sys/devices/system/cpu/cpu*/cpufreq/*" in the latest kernel, say, 3.10-rc1, both with and without processor.ignore_ppc.

There's no evidence that this is a regression.

This hansn't gone away. Finding a kernel which pre-dates this bug is almost impossible as I have seen it on a 3.0 kernel, I am now running 3.11... I do not have time to revert the system to a 2.6 kernel just to see if this reverts itself.

anton@smeg:~$  grep . /sys/devices/system/cpu/cpu*/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/bios_limit:700000
grep: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
/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/freqdomain_cpus:0 1
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
/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:600000
/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>
grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory
/sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/bios_limit:700000
grep: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: Permission denied
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:700000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:10000
/sys/devices/system/cpu/cpu1/cpufreq/freqdomain_cpus:0 1
/sys/devices/system/cpu/cpu1/cpufreq/related_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies:700000 600000 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:conservative ondemand userspace powersave performance 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:700000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpu1/cpufreq/stats: Is a directory
anton@smeg:~$ uname -a
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

This is again an Ubuntu kernel, I will try some more pure kernels at some point, but so far nothing has got any useful information out of my system other than the problem definitely exists...

There must be some real diagnostics I can try instead of this messing about with the same greps or cpufreq-info every time someone else has a look at this bug...

Hi Anton:
        Please check speedstep in your Bios. If it existed and was enabled, disable it and test again.

Hi Lan, 
There was an option for "GV1/GV3 P type power management" which once disabled seems to disable cpufreq from really doing much:
$ cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

$ ls /sys/devices/system/cpu/cpu*/cpufreq*
ls: cannot access /sys/devices/system/cpu/cpu*/cpufreq*:

I can't tell what frequency the system is running at, but presumably is no longer throttled

As I said, please attach the output of " grep . /sys/devices/system/cpu/cpu*/cpufreq/*" in the latest vanilla kernel you're using, both with and without boot option processor.ignore_ppc.

bug closed as there is no response from the bug reporter.
please feel free to re-open it once you can provide the information required in comment #29.

I no longer have the hardware so can't do anything on this

On 23 October 2014 08:53,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=43091
>
> Zhang Rui <rui.zhang@intel.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEEDINFO                    |CLOSED
>          Resolution|---                         |INSUFFICIENT_DATA
>
> --- Comment #30 from Zhang Rui <rui.zhang@intel.com> ---
> bug closed as there is no response from the bug reporter.
> please feel free to re-open it once you can provide the information required
> in
> comment #29.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.