CPU frequency stuck at minimum value

Bug #1769236 reported by Glen Ditchfield
60
This bug affects 12 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
koba
thermald (Ubuntu)
Incomplete
High
koba

Bug Description

I installed the Kubuntu variant of Ubuntu 18.04 on a new HP Spectre 13 laptop. Performance is poor. The CPU (an i7-8550U) is running at 400MHz, and never speeds up, even when running some of the Phoronix Test Suite benchmarks.

I can use cpupower to switch to the "performance" cpufreq governor, but cannot change the frequency with either governor.

Here is the output of some experiments I ran while Phoronix's c-ray test was running.
______________

gjditchf@copperplate:/var/log$ cat /proc/cpuinfo | grep MHz
cpu MHz : 400.008
cpu MHz : 400.002
cpu MHz : 400.002
cpu MHz : 400.003
cpu MHz : 400.005
cpu MHz : 400.003
cpu MHz : 400.001
cpu MHz : 400.004

gjditchf@copperplate:/var/log$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 1.60 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 400 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

gjditchf@copperplate:/var/log$ sudo cpupower frequency-set -f 1.60GHz
Setting cpu: 0
Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
   for example because of hardware which cannot be set to a specific frequency
   or because the userspace governor isn't loaded?

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-20-generic 4.15.0-20.21
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: KDE
Date: Fri May 4 12:57:25 2018
InstallationDate: Installed on 2018-04-28 (6 days ago)
InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: linux-signed
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: gjditchf 1190 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2018-04-28 (10 days ago)
InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 8087:0a2b Intel Corp.
 Bus 001 Device 003: ID 0bda:564e Realtek Semiconductor Corp.
 Bus 001 Device 002: ID 0bda:564f Realtek Semiconductor Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP HP Spectre Laptop 13-af0xx
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=UUID=ab54f00a-7dd6-4d75-a664-682f777c841c ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-20-generic N/A
 linux-backports-modules-4.15.0-20-generic N/A
 linux-firmware 1.173
Tags: bionic
Uname: Linux 4.15.0-20-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin monotone plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 10/13/2017
dmi.bios.vendor: Insyde
dmi.bios.version: F.06
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 83A2
dmi.board.vendor: HP
dmi.board.version: 55.24
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsyde:bvrF.06:bd10/13/2017:svnHP:pnHPSpectreLaptop13-af0xx:pvrType1ProductConfigId:rvnHP:rn83A2:rvr55.24:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Spectre
dmi.product.name: HP Spectre Laptop 13-af0xx
dmi.product.version: Type1ProductConfigId
dmi.sys.vendor: HP

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.17 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'.

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/v4.17-rc4

affects: linux-signed (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1769236

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

This was a fresh install, not an upgrade. I have applied all updates made available since the installation, but performance has not changed.

I have not installed any other linux on this laptop. For comparison purposes, I booted it from a 17.04 (Artful) live USB, which has kernel 4.13.0-16. It doesn't feel faster, but of course there are many factors involved ... When running Artful, /proc/cpuinfo displays "cpu MHz : 2000.000" for all 8 CPU's, and never varies. When running c-ray, all 8 CPUs are 50%--75% used, but the fans never spin up. "cpupower frequency-info" reports "current CPU frequency: 400 MHz (asserted by call to kernel)", which contradicts /proc/cpuinfo.

I will try an upstream kernel tomorrow.

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
Glen Ditchfield (gjditchfield) wrote : CRDA.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : IwConfig.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : Lspci.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : ProcEnviron.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : ProcModules.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : PulseList.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : RfKill.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : UdevDb.txt

apport information

Revision history for this message
Glen Ditchfield (gjditchfield) wrote : WifiSyslog.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

Upstream kernel 4.17.0-rc4 didn't change performance.

Recall that I installed Kubuntu. Since then I have installed ubuntu-gnome-desktop, in case that provided some missing configuration file.

With either kernel, I get this behavior:
- I boot the laptop.
- Instead of logging into a desktop environment, I use virtual terminals.
- Usually /proc/cpuinfo shows all 8 CPUs running at 900 MHz, give or take a few Hz. Sometimes it shows 400 MHz, but it soon rises to 900 MHz.
- I run the c-ray benchmark. CPU frequency rises to 2400 MHz, and stays there for tens of seconds, then drops to 400 MHz.
- The laptop does not become warm, and the fans do not spin up.
- I kill c-ray. A few minutes later, CPU frequency rises from 400 MHz back up to 900 MHz.
- kern.log contains "intel_powerclamp: Start idle injection to reduce power" within seconds of the times when the frequency drops to 400 MHz, and "intel_powerclamp: Stop forced idle injection" when it rises to 900 MHz.

Is the cooling system failing to activate the fans, or overreacting to CPU temperatures in some way?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Is it possible that it's thermal throttled by thermald?
You can disable thermald by executing `sudo systemctl stop thermald`.

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

With thermald stopped, and with the laptop displaying a desktop but not running any heavy loads, all 8 threads idle at 900 MHz, with all 4 cores typically running under 40°C.

When I run c-ray with thermald stopped, all 8 threads run at 2400 MHz and the cores warm up as high as 82°C, with short spikes up to 2700 MHz and 89°C. The fans run, but not at their maximum speed.
------
gjditchf@copperplate:/run/thermald$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +41.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +40.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +39.0°C (high = +100.0°C, crit = +100.0°C)
Core 2: +40.0°C (high = +100.0°C, crit = +100.0°C)
Core 3: +40.0°C (high = +100.0°C, crit = +100.0°C)

acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
temp2: +29.8°C (crit = +119.0°C)
temp3: +10.0°C

iwlwifi-virtual-0
Adapter: Virtual device
temp1: +32.0°C

pch_skylake-virtual-0
Adapter: Virtual device
temp1: +37.0°C
-------

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

I will attach /var/run/thermald/thermal-conf.xml.auto, and
thermal.log (generated by sudo thermald --no-daemon --loglevel=debug)
to illustrate thermald's bad behaviour.

Thermal.log up to line 500 shows the output when the laptop was idling:
sensor B0D4 stayed cooler than 40°C, the CPUs ran at 900 MHz, and
thermald is (I think) using rapl_controller for thermal control.

At that point I ran c-ray. CPU speed rose to 2400 MHz, and the
temperature began to rise (53°C at line 528, 64°C at line 632).

At line 656 thermald decided to switch from rapl_controller to
intel_pstate. At line 699 intel_pstate disabled turbo; CPU speed
dropped to 1800 MHz, and the temperature began to fall, from 71°C at
line 686 down to 54°C at line 799.

At that point, even though temperatures were falling and no fans were
running, thermald switched from intel_pstate to intel_powerclamp. CPU
speed dropped to 400 MHz, and performance tanked.

I think this switch to intel_powerclamp is the problem. It seems to
happen whenever the temperature exceeds 40°C for some number of polling
periods, which is not a useful thermal policy. Most web sites drive
the CPU hard enough to trigger it.

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :
Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

Should this bug be reassigned to thermald?

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

This seems to have wrong temperature threshold issue. 64C is too low threshold.
What is the dump of the following:
#grep -r . /sys/class/thermal/*

Meanwhile you can edit the file thermal-conf.xml.auto and change
<Temperature>*</Temperature>
to
<Temperature>95000</Temperature>
to make system usable.

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

Thanks for providing detailed logs. I see in the log:

"
cthd_sysfs_zone::read_cdev_trip_points: ZONE bound to CDEV status 0
Sorted trip dump zone index:5 type:B0D4:
index 2: type:passive temp:40000 hyst:1000 zone id:5 sensor id:5 cdev size:0
"

So this is a problem in configuration of the system.
So I suggest to either disable thermald or try what I suggested in comment #25.

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

Can you also attach output of acpidump?

#acpidump > acpi.out

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

I will attach acpi.out, and also the output of "grep -r . /sys/class/thermal/*" in grep-thermal.txt.

As for editing /var/run/thermald/thermal-conf.xml.auto ... that file is regenerated at boot. How do I make persistent changes? I tried copying the edited file to /etc/thermald/thermal-conf.xml, but didn't see any improvement, and the contents of the thermald debug log suggest that thermald doesn't read the /etc/ file.

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :
Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

/var/run/thermald/thermal-conf.xml.auto will not be regenerated, if present, so you can edit.

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

Thanks for providing the dump. Unfortunately the Spectre system has bad thermal table values (Since Windows 10 is using more advanced tables, manufacturer didn't notice bad values impact.). So there may be more systems like this. So I want to implement some workaroud. Can you give me dump of

# cat /sys/bus/acpi/devices/INT3400*/physical_node/uuids/*

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

No, /var/run/thermald/thermal-conf.xml.auto _is_ regenerated. I tried editing it. /var/run is a symbolic link to /run, which is a tmpfs.

The uuids directory contains two files. One is empty, and the other contains the word "INVALID".
===========
gjditchf@copperplate:/sys/bus/acpi$ cd /sys/bus/acpi/devices/INT3400*

gjditchf@copperplate:/sys/bus/acpi/devices/INT3400:00$ ls physical_node/uuids/
available_uuids current_uuid

gjditchf@copperplate:/sys/bus/acpi/devices/INT3400:00$ cat physical_node/uuids/available_uuids
gjditchf@copperplate:/sys/bus/acpi/devices/INT3400:00$ file physical_node/uuids/available_uuids
physical_node/uuids/available_uuids: empty

gjditchf@copperplate:/sys/bus/acpi/devices/INT3400:00$ cat physical_node/uuids/current_uuid
INVALID

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

If /var/run points to tmpfs then you can't change. Let me update a new version of thermald by working around this issue. But you have to build it yourself and try.

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

I have pushed workaround for this. Please try the latest thermald
https://github.com/intel/thermal_daemon/tree/v1.7.2-test
This should show version 1.7.2 when you do thermald --version.

Please test and let me know if the problem is fixed. Reboot your system to try new version, so that it will not try to create auto config files.

Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

I tried thermald 1.7.2, and I can make it work for me, but I don't
think it is the best solution. Please pardon the length at which I
explain my confusion.

I find the thermal-conf files to be confusing. Ubuntu 18.04's
thermald-1.7.0 package installs file /etc/thermald/thermal-conf.xml.
Based on the way other packages are configured, I would expect this to
be the configuration file, but thermald-1.7.0 ignores it. It seems to
be just a collection of examples.

Is that /etc/thermald/thermal-conf.xml file really suitable for every
system to use as a default configuration? If it is not OK, then the file
probably should be placed in /usr/share/doc instead of /etc.

The thermal-conf.xml.auto file that 1.7.0 generates for my system
seems to be OK, except for the Temperature element. Do you see any
other problems with it? As far as I know, my only problem is that I
can't override the generated Temperature.

My system runs well if I stop thermald. I don't know how much better
it would run *with* thermald, but "just stop thermald" seems to be an
acceptable fall-back position.

The new thermald-1.7.2 also attempts to read
/etc/thermald/thermal-conf.xml.auto, and I could edit a generated
thermal-conf.xml.auto to correct the Temperature element and put it
there. However, the ".auto" suffix would be misleading. I would
rather put the edited file in /etc/thermal-conf.xml.

Thermald-1.7.2 *only* reads the files in /etc if it *can't* generate
the /var/run file. It still doesn't provide a way to override a
successfully generated file. What if the generated file has a bug in
it? What if the user wants to fine-tune the configuration in some way?

Now consider what happens when I install thermald-1.7.2 on my 18.04
system. Similar things could happen to other people in the future, if
Cosmic Cuttlefish adopts 1.7.2 and other people upgrade to Cosmic from
18.04.

- Because of the int3400 check in line 169 of thd_trt_art_reader.cpp,
thermald does not try to generate
/var/run/thermald/thermal-conf.xml.auto.

- Then cthd_parse::parser_init() looks for
  /etc/thermald/thermal-conf.xml.auto, and does not find
  it.

- Finally cthd_parse::parser_init() looks for
  /etc/thermald/thermal-conf.xml, finds the
  "examples" file, and loads it. As I mentioned above, I don't know
  if that's a good idea.

---------

I'd like to suggest the following:

- The thermald package should *not* install
  /etc/thermald/thermal-conf.xml.

- thermald should first look for /etc/thermald/thermal-conf.xml and
  load it if it exists.

- If /etc/thermald/thermal-conf.xml does not exist, thermald should
  generate /var/run/thermald/thermal-conf.xml.auto and load it.

---------

Two unimportant points:

- The new thd_log_info message at thd_trt_art_reader.cpp, line 170,
should end with a \n.

- I recommend that cthd_parse::parser_init() log the chosen
xml_config_file's name every time, not just if it chooses the
generated file.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thermald (Ubuntu):
status: New → Confirmed
Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

Glen:
Thanks for good suggestions. I will consider for next revision.

But problem in this bugzilla is addressed. This system has buggy temperature threshold. OEM didn't find because Windows will not use any more.

So with the change we really look if Windows would have used this threshold based on UUID, if not Linux will not use it too.

Revision history for this message
emanuele ghedini (emanuele-ghedini) wrote :

According to:

https://askubuntu.com/questions/1067866/ubuntu-18-04-steam-games-frame-rate-drop/1073353#1073353?newreg=c7c120f373da4effb7317104571cd573

The problem is related to irqbalance and the solution is to remove it:
sudo apt remove irqbalance

Checked in my laptop and it works.

Revision history for this message
Pablo Catalina (xkill) wrote :

Seems similar to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1811730

I fixed the problem using the latest version of thermald from git.

Revision history for this message
Pete (pt.pete.pt) wrote :

Would it be possible to include a newer version of thermald (was probably fixed in 1.7.2 according to release notes) in Ubuntu? I have a similar issue and it's quite annoying.

Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
Maarten van Dootingh (theoke) wrote :

I can confirm this bug is still there in Ubuntu 20.04 (and from what i did find it already exists at least 13 years!). I think this should get some priority.

I have a Dell XPS13 for 1.5 year now and this haunted me ever since.
I recently discovered that i can restore normal operation by temporary unplugging the external power a few times. About 1 in 4 times normal operation is restored.
I check this using cpufreq-info | grep MHz

Revision history for this message
Colin Ian King (colin-king) wrote :

@folks, does the latest thermald resolve this issue?

Changed in thermald (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Glen Ditchfield (gjditchfield) wrote :

I am now running KDE Neon, which comes with thermald 1.9.1-1ubuntu0.3, and have not noticed any problems. The fans certainly spin up under load.

Revision history for this message
Jori Niemi (jornbit) wrote :

After upgrading to thermald (1.9.1-1ubuntu0.4) my laptop is constantly throttled to 400-800 MHz even under single core load, while CPU temperature is under 55°C. The previous version was 1.9.1-1ubuntu0.3 and I had no problems back then.

When thermald is disabled, after a minute of rendering in Blender my CPU temp is 66°C and clocks are around 2400 to 2500 MHz.

My laptop is a Thinkpad P53s with a i7-8665U CPU on Mint 20.1 (based on Ubuntu 20.04 LTS).

Revision history for this message
Srinivas Pandruvada (srinivas-pandruvada) wrote :

If possible please try to build from
https://github.com/intel/thermal_daemon

Revision history for this message
Gerald Schroll (schroll) wrote :

Compiling thermald 2.4.6 from source solved the issue for us on a Dell Latitude 7400. This bug is hard to spot. We were almost about to exchange the hard drive, which would not have helped. Please include the fixes in the official Ubuntu package. It would save many other people spending hours of troubleshooting.

Revision history for this message
Colin Ian King (colin-king) wrote :

@Gerald, can you inform me which release you are using an the version of thermald you were using when you observed this bug? I'll double check to see if any backported fixes are missing.

Changed in linux (Ubuntu):
assignee: nobody → Colin Ian King (colin-king)
Changed in thermald (Ubuntu):
assignee: nobody → Colin Ian King (colin-king)
Revision history for this message
Gerald Schroll (schroll) wrote :

The installed version is 1.9.1-1ubuntu0.4.

Revision history for this message
Colin Ian King (colin-king) wrote :

Thermald 1.9.1-1ubuntu0.4 contains the backport of the adaptive engine, see bug https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1913186

Thermald 1.9.1-1ubuntu.05 contains the following fixes that may also be useful:

   - Disable legacy rapl cdev when rapl-mmio is in use
     This will prevent PL1/PL2 power limit from MSR based rapl, which
     may not be the correct one.
   - Delete all trips from zones before psvt install
     Initially zones has all the trips from sysfs, which may have wrong
     settings. Instead of deleting only for matched psvt zones, delete
     or all zones. In this way only zones which are in PSVT will be
     present.
   - Check for alternate names for B0D4 device
     B0D4 can be named as TCPU or B0D4. So search for both names
     if failed to find one.
   - Fix error for condition names
     The current code caps the max name as the last condition name,
     which is "Power_Slider". So any condition more than 56 will be
     printing error, with "Power_Slider" as condition name. For example
     for condition = 57: Unsupported condition 57 (Power_slider)
   - Set a very high RAPL MSR PL1 with --adaptive
     After upgrading Dell Latitude 5420, again noticed performance
     degradation.
     The PPCC power limit for MSR RAPL PL1 is reduced to 15W. Even though
     we disable MSR RAPL with --adaptive option, it is not getting
     disabled. So MSR RAPL limits still playing role.
     To fix that set a very high MSR RAPL PL1 limit so that it never
     causes throttling. All throttling with --adaptive option is done
     using RAPL-MMIO.
   - Special case for default PSVT
     When there are no adaptive tables and only one default PSVT table
     is present with just one entry with MAX type. Add one additional
     entry as done for non default case.
   - Increase power limit for disabled RAPL-MMIO
     Increase 100W to 200W as some desktop platform already have limit
     more than 100W.
   - Use Adaptive PPCC limits for RAPL MMIO
     Set the correct device name as RAPL-MSR so that RAPL-MMIO can
     also set the correct default power limits.

So first step is to see if thermald 1.9.1-1ubuntu0.5 helps.

Changed in thermald (Ubuntu):
importance: Undecided → High
Revision history for this message
Colin Ian King (colin-king) wrote :

@Gerald, did thermald 1.9.1-1ubuntu0.5 help resolve the issue?

Revision history for this message
Gerald Schroll (schroll) wrote :

@Colin, please excuse my late response. Version 1.9.1-1ubuntu0.5 unfortunately shows the same behavior. My colleague switched to the self compiled version again.

Changed in linux (Ubuntu):
assignee: Colin Ian King (colin-king) → Ubuntu Kernel Team (ubuntu-kernel-team)
Changed in thermald (Ubuntu):
assignee: Colin Ian King (colin-king) → Ubuntu Kernel Team (ubuntu-kernel-team)
Changed in linux (Ubuntu):
assignee: Ubuntu Kernel Team (ubuntu-kernel-team) → koba (kobako)
Changed in thermald (Ubuntu):
assignee: Ubuntu Kernel Team (ubuntu-kernel-team) → koba (kobako)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.