Score:0

intel_pstate driver not being loaded when added to grub file

cz flag

I have a

Processor   Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
Memory  16305MB (2531MB used)
Machine Type    Laptop
Operating System    Ubuntu 20.04.3 LTS

In my /etc/default/grub file I have the line

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=enable"

I did a sudo update-grub after the changes but when I do a cpupower frequency-info or a cpufreq-info --driver it says the driver used is intel_cpufreq

rt@sys76:~$ cpufreq-info --driver
intel_cpufreq


rt@sys76:~$ cpupower frequency-info

analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 800 MHz - 3.40 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 1.70 GHz and 3.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 798 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
rt@sys76:~$ 

How can I get the cpufreq-info --driver to use intel_pstate driver?

Score:2
gn flag

Your processor, i7-4700MQ, predates HWP (HardWare Pstate) control. The migration path as determined by the kernel power management group, for these Intel processors is to default towards the intel_pstate CPU frequency scaling driver being in passive mode using the schedutil scaling governor. To that end this commit was done:

commit 33aa46f252c703e42c81a76696cd0c240f2281e4 Author: Rafael J. Wysocki [email protected] Date: Wed Mar 25 15:03:35 2020 +0100

cpufreq: intel_pstate: Use passive mode by default without HWP

After recent changes allowing scale-invariant utilization to be
used on x86, the schedutil governor on top of intel_pstate in the
passive mode should be on par with (or better than) the active mode
"powersave" algorithm of intel_pstate on systems in which
hardware-managed P-states (HWP) are not used, so it should not be
necessary to use the internal scaling algorithm in those cases.

Accordingly, modify intel_pstate to start in the passive mode by
default if the processor at hand does not support HWP of if the driver
is requested to avoid using HWP through the kernel command line.

Among other things, that will allow utilization clamps and the
support for RT/DL tasks in the schedutil governor to be utilized on
systems in which intel_pstate is used.

You are actually using the intel_pstate CPU frequency scaling driver, however it is in passive mode. Try this:

echo active | sudo tee /sys/devices/system/cpu/intel_pstate/status

and then check:

cat /sys/devices/system/cpu/intel_pstate/status

If that works as expected then change your grub line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=active"

and see if it boots the way you want.

Note that the CPU Frequency scaling driver intel_cpufreq is just the intel_pstate driver in passive mode.

Example:

doug@s19:~/temp$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu10/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu11/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu4/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu6/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu7/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu8/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu9/cpufreq/scaling_driver:intel_cpufreq

doug@s19:~/temp$ cat /sys/devices/system/cpu/intel_pstate/status
passive
doug@s19:~/temp$ echo active | sudo tee /sys/devices/system/cpu/intel_pstate/status
active

doug@s19:~/temp$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu10/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu11/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu4/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu6/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu7/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu8/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu9/cpufreq/scaling_driver:intel_pstate
cz flag
Thanks, changing the grub file worked but it still boots up into "powersave" mode when checking the scaling.
Doug Smythies avatar
gn flag
@RickT : Yes, that is correct. If the intel_pstate scaling driver is "active" then "powersave" is the default governor. If the driver "passive" or the is the acpi-cpufreq driver during boot, then the default governor will be "ondemand". Note that "active-powersave" is crudely the equivalent of "passive-ondemand". You can eliminate these default settings by stopping and disabling the "ondemand" service.
Score:0
cz flag

The power supply for the laptop stopped working and I replaced it. All of a sudden the cpu's started working properly again. Looks like the power supply was going bad and not putting out enough current.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.