Cannot disable intel_pstate driver

Support
1

I cannot disable intel_pstate. As per ArchWiki I added intel_pstate=disable to the kernel command line. I can see in dmesg it was passed:

[    0.090261] Kernel command line: BOOT_IMAGE=/@/boot/vmlinuz-6.0-x86_64 root=UUID=ffdc12f7-1afb-495a-a648-007b7a792e61 rw rootflags=subvol=@ quiet apparmor=1 security=apparmor udev.log_priority=3 ibt=off intel_pstate=disable

Yet, later in dmesg I see:

[    1.012183] intel_pstate: HWP enabled by BIOS
[    1.012185] intel_pstate: Intel P-state driver initializing
[    1.014321] intel_pstate: HWP enabled

And after the boot I can check that intel_pstate is being used:

$ 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 - 5.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.00 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.42 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

intel_pstate is very conservative. Even if I set the governor to performance, all cores are very slowly pacing, keeping the CPU package temperature under 60°C under the full load of every core. I usually get much better results with Schedutil governor, for which I have to disable intel_pstate. How? What am I missing?

2

if you edit grub you have to run

sudo update-grub

you did ? if not run it after editing grub

3

I am sorry, but I don’t think you read my message carefully. I posted the actual kernel command line that was used during the boot process. You might have assumed that I’ve done the previous steps correctly, since whatever magic was used with grub, it probably was correct (and thus irrelevant) because the intel_pstate=disable parameter was passed to the kernel.

4

please edit grub and add the parameter to the existing ones at the line

GRUB_CMDLINE_LINUX_DEFAULT=

after saving run the following

sudo mkinitcpio -P
sudo update-grub

and yes i already read your message.

A better way is to create a udev-rule. if your not keen ask for advice

5

I’ve done that ( mkinitcpio -P is absolutely useless in this case, btw). The parameter is being passed to the kernel command line.

intel_pstate is not a loadable module, you cannot blacklist it, the maximum you can do with udev is change the governor or some other parameters of intel_pstate. You cannot entirely disable it with udev.

My question is: why intel_pstate=disable passed to the kernel has no effect? Can you answer this?

6

My hypothesis would be that presently the kernel hasn’t implemented any alternative to intel_pstate for my CPU (12th Gen Intel Core i9) yet, and, thus, even if you pass intel_pstate=disable, the kernel simply ignores it and loads intel_pstate anyway.

7

perhaps you need to actively load the module
acpi_cpufreq
in addition to disabling the intel_pstate driver
?

There was also this thread here..
Perhaps you can glean something from it.

8

…
no comment

9

It’s not a loadable module. Per ArchWiki, to activate it, one has to pass intel_pstate=disable to the kernel command line. Do you know other methods?

10

I know.
intel_pstate is not a loadable module
however:
acpi_cpufreq is …

11

Which can be only loaded, if intel_pstate is disabled? Let me try anyway.

12

create a file “99-governor-rules.rules” and store it in /etc/udev/rules.d

## ACTION TO DO WHEN ON BATTERY
SUBSYSTEM=="power_supply", ACTION=="change", ENV{POWER_SUPPLY_ONLINE}=="0", ENV{POWER}="off", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/YOURUSERNAME/.Xauthority", RUN+="/usr/bin/cpupower frequency-set --governor ondemand"

## ACTION TO DO WHEN ON CHARGER
SUBSYSTEM=="power_supply", ACTION=="change", ENV{POWER_SUPPLY_ONLINE}=="1", ENV{POWER}="on", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/YOURUSERNAME/.Xauthority", RUN+="/usr/bin/cpupower frequency-set --governor performance"

p.s.: don’t miss to change YOURUSERNAME to yours.

reboot and feel good

13

As I said before, this doesn’t disable intel_pstate, it just changes the governor, which I can do without udev and dances with the tambourine.

14

Seems like this has no effect. I guess because intel_pstate was activated at boot

$ sudo modprobe acpi_cpufreq
$ lsmod | grep acpi
snd_soc_acpi_intel_match    69632  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_soc_acpi           16384  2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common
snd_intel_sdw_acpi     20480  2 snd_sof_intel_hda_common,snd_intel_dspcfg
i2c_hid_acpi           16384  0
i2c_hid                40960  1 i2c_hid_acpi
acpi_thermal_rel       16384  1 int3400_thermal
acpi_tad               20480  0
acpi_pad               24576  0
15

It was my guess.

I can’t make sense of the explanation given here

that intel_pstate is in passive mode …

This is beyond me and my knowledge - sorry!

16

I’ll take a look tomorrow. Thanks!

17

Setting intel_pstate=passive did help to get schedutil governor available. Strangely, cpufreq.default_governor=schedutil didn’t work, but I could set the governor after login. However, schedutil didn’t solve the main issue: the performance is still low, something keeps the CPU temperature under 57 °C (strange number, maybe whoever wrote the configuration was an American and thought of 135 °F?). This is another issue, though, so I mark this topic as resolved and will continue digging.

P.S. A funny consequence of this issue is that on this machine, Linux is faster running inside a VirtualBox from Windows than on the real hardware.

18

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.