Bug 58001

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.