On a Dell XPS 12 (Intel Core i7-3537U), I experience exactly the same symptoms as in bug #14771, except it has nothing to do with the power supply: I'm using the stock power supply, and the problematic behavior is observed both on battery and on AC power. If I keep the default settings, the CPU frequency never goes beyond the 800 MHz minimum, regardless of the CPU load. If I decrease /sys/devices/system/cpu/cpufreq/ondemand/up_threshold from the default value of 95 to 75, then the processors dynamically switch back and forth from 800 MHz to 2 GHz according to CPU load.
On Sat, May 11, 2013 at 3:02 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=58001 > > Summary: "ondemand" CPU governor never raises frequency (Dell > XPS 12) > Product: Power Management > Version: 2.5 > Kernel Version: 3.8.11-200.fc18.x86_64 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: cpufreq > AssignedTo: cpufreq@vger.kernel.org > ReportedBy: jylefort@gmail.com > Regression: No > > > On a Dell XPS 12 (Intel Core i7-3537U), I experience exactly the same > symptoms > as in bug #14771, except it has nothing to do with the power supply: I'm > using > the stock power supply, and the problematic behavior is observed both on > battery and on AC power. > > If I keep the default settings, the CPU frequency never goes beyond the 800 > MHz > minimum, regardless of the CPU load. > > If I decrease /sys/devices/system/cpu/cpufreq/ondemand/up_threshold from the > default value of 95 to 75, then the processors dynamically switch back and > forth from 800 MHz to 2 GHz according to CPU load. It sort of means system isn't loaded well :) Can you paste/attach output of cpufreq-info?
There is no such tool on my system (Fedora 18), I assume this is the same: $ cpupower -c all frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 800 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 800 MHz. boost state support: Supported: yes Active: yes 25500 MHz max turbo 4 active cores 25500 MHz max turbo 3 active cores 25500 MHz max turbo 2 active cores 25500 MHz max turbo 1 active cores analyzing CPU 1: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 1 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 800 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 800 MHz. boost state support: Supported: yes Active: yes 25500 MHz max turbo 4 active cores 25500 MHz max turbo 3 active cores 25500 MHz max turbo 2 active cores 25500 MHz max turbo 1 active cores analyzing CPU 2: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 2 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 800 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 800 MHz. boost state support: Supported: yes Active: yes 25500 MHz max turbo 4 active cores 25500 MHz max turbo 3 active cores 25500 MHz max turbo 2 active cores 25500 MHz max turbo 1 active cores analyzing CPU 3: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 3 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 800 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 800 MHz. boost state support: Supported: yes Active: yes 25500 MHz max turbo 4 active cores 25500 MHz max turbo 3 active cores 25500 MHz max turbo 2 active cores 25500 MHz max turbo 1 active cores
On Sun, May 12, 2013 at 10:25 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=58001 > > > > > > --- Comment #2 from Jean-Yves Lefort <jylefort@gmail.com> 2013-05-12 > 16:55:08 --- > There is no such tool on my system (Fedora 18), I assume this is the same: > > $ cpupower -c all frequency-info > analyzing CPU 0: > driver: acpi-cpufreq > CPUs which run at the same hardware frequency: 0 1 2 3 > CPUs which need to have their frequency coordinated by software: 0 > maximum transition latency: 10.0 us. > hardware limits: 800 MHz - 2.00 GHz > available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 > GHz, > 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 > MHz, > 800 MHz > available cpufreq governors: conservative, userspace, powersave, ondemand, > performance > current policy: frequency should be within 800 MHz and 2.00 GHz. > The governor "ondemand" may decide which speed to use > within this range. > current CPU frequency is 800 MHz. > boost state support: > Supported: yes > Active: yes > 25500 MHz max turbo 4 active cores > 25500 MHz max turbo 3 active cores > 25500 MHz max turbo 2 active cores > 25500 MHz max turbo 1 active cores > analyzing CPU 1: > driver: acpi-cpufreq > CPUs which run at the same hardware frequency: 0 1 2 3 > CPUs which need to have their frequency coordinated by software: 1 > maximum transition latency: 10.0 us. > hardware limits: 800 MHz - 2.00 GHz > available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 > GHz, > 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 > MHz, > 800 MHz > available cpufreq governors: conservative, userspace, powersave, ondemand, > performance > current policy: frequency should be within 800 MHz and 2.00 GHz. > The governor "ondemand" may decide which speed to use > within this range. > current CPU frequency is 800 MHz. > boost state support: > Supported: yes > Active: yes > 25500 MHz max turbo 4 active cores > 25500 MHz max turbo 3 active cores > 25500 MHz max turbo 2 active cores > 25500 MHz max turbo 1 active cores > analyzing CPU 2: > driver: acpi-cpufreq > CPUs which run at the same hardware frequency: 0 1 2 3 > CPUs which need to have their frequency coordinated by software: 2 > maximum transition latency: 10.0 us. > hardware limits: 800 MHz - 2.00 GHz > available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 > GHz, > 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 > MHz, > 800 MHz > available cpufreq governors: conservative, userspace, powersave, ondemand, > performance > current policy: frequency should be within 800 MHz and 2.00 GHz. > The governor "ondemand" may decide which speed to use > within this range. > current CPU frequency is 800 MHz. > boost state support: > Supported: yes > Active: yes > 25500 MHz max turbo 4 active cores > 25500 MHz max turbo 3 active cores > 25500 MHz max turbo 2 active cores > 25500 MHz max turbo 1 active cores > analyzing CPU 3: > driver: acpi-cpufreq > CPUs which run at the same hardware frequency: 0 1 2 3 > CPUs which need to have their frequency coordinated by software: 3 > maximum transition latency: 10.0 us. > hardware limits: 800 MHz - 2.00 GHz > available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 > GHz, > 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 > MHz, > 800 MHz > available cpufreq governors: conservative, userspace, powersave, ondemand, > performance > current policy: frequency should be within 800 MHz and 2.00 GHz. > The governor "ondemand" may decide which speed to use > within this range. > current CPU frequency is 800 MHz. > boost state support: > Supported: yes > Active: yes > 25500 MHz max turbo 4 active cores > 25500 MHz max turbo 3 active cores > 25500 MHz max turbo 2 active cores > 25500 MHz max turbo 1 active cores Can you give a try with 3.9 kernel?
Hi Jean-Yves: Could you try v3.10-rc4 kernel and using intel_pstate driver?
Any update?
I no longer have this machine so I cannot help.
Perhaps ask Dell to provide you with one, I suppose it's in their interest to have this bug fixed. The XPS 12 is a wonderful machine, but because of this bug, it appears as a slow machine, nothing good for Dell there.
Ok. So the machine is not availabe and we can't get more info. So close this bug as INSUFFICIENT_DATA. If DELL give me one, I'd like to fix it. :) Anyway, thanks for response.
I'm not sure why this bug is reopened. But we can not make any progress because there is no way to reproduce/debug the issue. Bug closed.
This becauses Raymond said he had such machine and would debug. I have asked him to try v3.12-rc1 kernel but no response http://markmail.org/message/ovbop4rizgwwumdv
okay, then I think you can reopen it if Raymond can help debug.
Hello, Please forgive the long delay. However, I do have this machine still and even with Linux rotty-xps 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I still get the problem. I can help debug if you still want to try to solve the problem.
Effectively, I have exactly the same issue as outlined above. The 'ondemand' governor never reacts to changes in system load, no matter what the system is doing. However, the other governors all work perfectly. I generally place my machine in 'conservative' and that seems to work fine. When I'm going a build and need more power I switch to performance. the output of cpufreq-info is: cpufrequtils 008: 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 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 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 2.00 GHz. The governor "conservative" may decide which speed to use within this range. current CPU frequency is 800 MHz. cpufreq stats: 2.00 GHz:-nan%, 2.00 GHz:-nan%, 1.90 GHz:-nan%, 1.80 GHz:-nan%, 1.70 GHz:-nan%, 1.60 GHz:-nan%, 1.50 GHz:-nan%, 1.40 GHz:-nan%, 1.30 GHz:-nan%, 1.20 GHz:-nan%, 1.10 GHz:-nan%, 1000 MHz:-nan%, 900 MHz:-nan%, 800 MHz:-nan% (403) analyzing CPU 1: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 1 CPUs which need to have their frequency coordinated by software: 1 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 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 2.00 GHz. The governor "conservative" may decide which speed to use within this range. current CPU frequency is 800 MHz. cpufreq stats: 2.00 GHz:-nan%, 2.00 GHz:-nan%, 1.90 GHz:-nan%, 1.80 GHz:-nan%, 1.70 GHz:-nan%, 1.60 GHz:-nan%, 1.50 GHz:-nan%, 1.40 GHz:-nan%, 1.30 GHz:-nan%, 1.20 GHz:-nan%, 1.10 GHz:-nan%, 1000 MHz:-nan%, 900 MHz:-nan%, 800 MHz:-nan% (382) analyzing CPU 2: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 2 CPUs which need to have their frequency coordinated by software: 2 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 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 2.00 GHz. The governor "conservative" may decide which speed to use within this range. current CPU frequency is 800 MHz. cpufreq stats: 2.00 GHz:-nan%, 2.00 GHz:-nan%, 1.90 GHz:-nan%, 1.80 GHz:-nan%, 1.70 GHz:-nan%, 1.60 GHz:-nan%, 1.50 GHz:-nan%, 1.40 GHz:-nan%, 1.30 GHz:-nan%, 1.20 GHz:-nan%, 1.10 GHz:-nan%, 1000 MHz:-nan%, 900 MHz:-nan%, 800 MHz:-nan% (445) analyzing CPU 3: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 3 CPUs which need to have their frequency coordinated by software: 3 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 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 2.00 GHz. The governor "conservative" may decide which speed to use within this range. current CPU frequency is 800 MHz. cpufreq stats: 2.00 GHz:-nan%, 2.00 GHz:-nan%, 1.90 GHz:-nan%, 1.80 GHz:-nan%, 1.70 GHz:-nan%, 1.60 GHz:-nan%, 1.50 GHz:-nan%, 1.40 GHz:-nan%, 1.30 GHz:-nan%, 1.20 GHz:-nan%, 1.10 GHz:-nan%, 1000 MHz:-nan%, 900 MHz:-nan%, 800 MHz:-nan% (354)
I see problem too. May not be kernel, but in Ubuntu in particular. I think the up_threshold is set at 95, too high, and keeping it lower is a bit of a hassle. My system now: $ uname -a Linux dellap7 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux CPU never goes fast in ondemand unless I do this: su -c "echo -n 70 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold" I find 70 is low enough to solve the sluggishness problem in Ubuntu. I wanted to make that permanent. Its not easy in newer Ununtu. I find that suggestions to edit /etc/sysfs.conf are unhelpful. I found one post that claims that the Ubuntu stack does not create /sys/devices/system/cpu/cpufreq/ondemand soon enough, so the sysfs adjustments have no effect. The best explanation I've found is #5 in this thread https://bugs.launchpad.net/ubuntu/+source/sysfsutils/+bug/955918. A suggestion is to insert this in /etc/rc.local, so it will run, or wait until the rest of the system has done what it is supposed to. I've not got advice from an expert on whether this is bad or good, but I'm doing it, following that example. until [ -d "/sys/devices/system/cpu/cpufreq/ondemand" ]; do sleep 1 done echo -n "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold Another thing users with same up_threshold problem might benefit from use of a applet that can turn CPUs to performance mode instantly. It works in user space, no admin required (that was a new thing to me, anyway). Look for this: indicator-cpufreq That's handy when you can't seem to get the CPUs to go fast. Performance mode makes a laptop hotter (in several senses :) ). From a user's point of view, this has all become very confusing. What is controlling speed now? There's no cpufreqd anymore? Some guidance from kernel experts would be pleasant. There were posts claiming that Intel discouraged ondemand, maybe that factors into problem (Intel Dev says "Stop using OnDemand!!!" https://bbs.archlinux.org/viewtopic.php?id=163524&p=2). I suppose that must have been bogus, since we are still using ondemand a year later. But not cpufreqd, so far as I can tell, in a fresh Ubuntu install.
I can confirm that this operation does work for me. Having a way of setting this as the system default would be great.
Can anybody seeing this problem with ondemand please see if intel_pstates works for them or not?
(In reply to Len Brown from comment #16) > Can anybody seeing this problem with ondemand > please see if intel_pstates works for them or not? I can test this with guidance. Please tell me which steps to take.
currently I have ~]$ cpufreq-info | grep driver driver: acpi-cpufreq driver: acpi-cpufreq driver: acpi-cpufreq driver: acpi-cpufreq How now to enabled the intel_pstate driver. I've tried from the grub boot menu to add set intel_pstate=enable with no luck. (of course this might be completely wrong way to do it...)
(In reply to Raymond Auge from comment #18) > currently I have > > > ~]$ cpufreq-info | grep driver > driver: acpi-cpufreq > driver: acpi-cpufreq > driver: acpi-cpufreq > driver: acpi-cpufreq > > How now to enabled the intel_pstate driver. > > I've tried from the grub boot menu to add > > set intel_pstate=enable > > with no luck. (of course this might be completely wrong way to do it...) my kernel version is ~]$ uname -a Linux rotty-xps 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
intel_pstate=enable on the proper grub line should work. Here is an example from mine (/etc/default/grub): GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 intel_pstate=enable crashkernel=384M-:128M" Of course, run "sudo update-grub" afterwards.
Ok this seems to give working governance (2 levels only powersave, performance) and I'm apparently seeing CPU frequencies beyond those previously available, which were 800MHz-2000MHz Now I see: ~]$ sudo dmidecode -t processor | grep MHz External Clock: 100 MHz Max Speed: 4000 MHz Current Speed: 2000 MHz and the cpu speed in powersave hovers around: ~]$ grep MHz /proc/cpuinfo cpu MHz : 1553.320 cpu MHz : 1560.644 cpu MHz : 2186.230 cpu MHz : 1757.519
Is it possible that different Intel chips respond differently? I'm running Ubuntu 14.04 on 2 laptops and one has the problem, the other does not. On the Dell Precision m4600 laptop, I had the chronic problem that, after suspend, I was always stuck at 800MHZ. To fix that, I had to explicitly reset the threshold lower. Eventually, I found a script that did it #!/bin/bash ## https://gist.github.com/Pyppe/6028707 # default with 13.04 is 95 SCALING_FILE=/sys/devices/system/cpu/cpufreq/ondemand/up_threshold defvalue=70 if [ ! -f "$SCALING_FILE" ]; then echo "$SCALING_FILE not found" exit 1 fi limit=${1:-$defvalue} if [[ $limit -lt 100 && $limit -gt 30 ]]; then sudo bash -c "echo $limit > $SCALING_FILE" else echo "Invalid value" exit 1 fi However, on a Dell Latitude 6430u, I have no such problem. Frequency scaling works without qualification, before and after suspend.
Unfortunately after an recent upgrade of ubuntu ~]$ uname -a Linux rotty-xps 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux ~]$ lsb_release -cir Distributor ID: Ubuntu Release: 14.04 Codename: trusty the issue has re-appeared, but now with the intel_pstate driver. ~]$ cpufreq-info | grep driver driver: intel_pstate driver: intel_pstate driver: intel_pstate driver: intel_pstate It's no longer managing the CPU frequency which remains at ~]$ grep MHz /proc/cpuinfo cpu MHz : 806.250 cpu MHz : 806.250 cpu MHz : 806.250 cpu MHz : 806.250 Even loading the cpu while watching the frequency (watch -n.5 "grep MHz /proc/cpuinfo") shows no frequency changes and the machine is incredibly slow.
please attach the output of "grep . /sys/class/thermal/thermal*/*".
~]$ grep . /sys/class/thermal/thermal*/* grep: /sys/class/thermal/thermal_zone0/emul_temp: Permission denied /sys/class/thermal/thermal_zone0/policy:(null) grep: /sys/class/thermal/thermal_zone0/power: Is a directory grep: /sys/class/thermal/thermal_zone0/subsystem: Is a directory /sys/class/thermal/thermal_zone0/temp:58000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:0 /sys/class/thermal/thermal_zone0/trip_point_0_type:passive /sys/class/thermal/thermal_zone0/trip_point_1_temp:0 /sys/class/thermal/thermal_zone0/trip_point_1_type:passive /sys/class/thermal/thermal_zone0/type:pkg-temp-0 (Note: I have already reverted to acpi-cpufreq and now it seems to be reliably working when it was not before.)
(In reply to Raymond Auge from comment #25) > ~]$ grep . /sys/class/thermal/thermal*/* > grep: /sys/class/thermal/thermal_zone0/emul_temp: Permission denied > /sys/class/thermal/thermal_zone0/policy:(null) > grep: /sys/class/thermal/thermal_zone0/power: Is a directory > grep: /sys/class/thermal/thermal_zone0/subsystem: Is a directory > /sys/class/thermal/thermal_zone0/temp:58000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp:0 > /sys/class/thermal/thermal_zone0/trip_point_0_type:passive > /sys/class/thermal/thermal_zone0/trip_point_1_temp:0 > /sys/class/thermal/thermal_zone0/trip_point_1_type:passive > /sys/class/thermal/thermal_zone0/type:pkg-temp-0 > this is buggy, the passive trip point is 0C which does not make sense. please clear CONFIG_ACPI_THERMAL and CONFIG_THERMAL and see if the cpu frequency works well or not. please attach the acpidump output.
(In reply to Zhang Rui from comment #26) > (In reply to Raymond Auge from comment #25) > > ~]$ grep . /sys/class/thermal/thermal*/* > > grep: /sys/class/thermal/thermal_zone0/emul_temp: Permission denied > > /sys/class/thermal/thermal_zone0/policy:(null) > > grep: /sys/class/thermal/thermal_zone0/power: Is a directory > > grep: /sys/class/thermal/thermal_zone0/subsystem: Is a directory > > /sys/class/thermal/thermal_zone0/temp:58000 > > /sys/class/thermal/thermal_zone0/trip_point_0_temp:0 > > /sys/class/thermal/thermal_zone0/trip_point_0_type:passive > > /sys/class/thermal/thermal_zone0/trip_point_1_temp:0 > > /sys/class/thermal/thermal_zone0/trip_point_1_type:passive > > /sys/class/thermal/thermal_zone0/type:pkg-temp-0 > > > this is buggy, the passive trip point is 0C which does not make sense. > please clear CONFIG_ACPI_THERMAL and CONFIG_THERMAL and see if the cpu > frequency works well or not. > please attach the acpidump output. Sorry for the delay. Where do I find these values/settings/configurations?
(In reply to Raymond Auge from comment #27) > (In reply to Zhang Rui from comment #26) > > (In reply to Raymond Auge from comment #25) > > > ~]$ grep . /sys/class/thermal/thermal*/* > > > grep: /sys/class/thermal/thermal_zone0/emul_temp: Permission denied > > > /sys/class/thermal/thermal_zone0/policy:(null) > > > grep: /sys/class/thermal/thermal_zone0/power: Is a directory > > > grep: /sys/class/thermal/thermal_zone0/subsystem: Is a directory > > > /sys/class/thermal/thermal_zone0/temp:58000 > > > /sys/class/thermal/thermal_zone0/trip_point_0_temp:0 > > > /sys/class/thermal/thermal_zone0/trip_point_0_type:passive > > > /sys/class/thermal/thermal_zone0/trip_point_1_temp:0 > > > /sys/class/thermal/thermal_zone0/trip_point_1_type:passive > > > /sys/class/thermal/thermal_zone0/type:pkg-temp-0 > > > > > this is buggy, the passive trip point is 0C which does not make sense. > > please clear CONFIG_ACPI_THERMAL and CONFIG_THERMAL and see if the cpu > > frequency works well or not. > > please attach the acpidump output. > > Sorry for the delay. Where do I find these values/settings/configurations? seems this requires rebuilding the kernel... It's been a while. Plus this is a ubuntu kernel, but it shouldn't be too hard. Expect delays.
please attach the acpidump of the machine and kernel config file.
ping...
(In reply to Zhang Rui from comment #30) > ping... My apologies for the delay! At one point I did a kernel (stock ubuntu) upgrade and then the default driver was suddenly intel_pstate. Furthermore, the governor worked as expected. That being the case, I think that unless someone else is still suffering this issue, it could probably considered "fixed". PS: Thank you all for your time and efforts! They are very much appreciated.