i5 10400 not using intel_pstate as power management driver

[Recede9303]

Hey, trying to figure something out on the power management bit and either I don't know how to search for it or I'm too dumb to understand it so figured I'd ask people more experienced than me .

One of my Proxmox nodes is an i5 10400 with an asrock motherboard. It all works great but when looking at some guides to try to optimize the power usage I noticed that it's not using the intel_pstate driver for power management and instead uses the intel_cpufreq which as far as I know is the fallback when the CPU is too old to support pstates. I'm pretty sure a 10th gen CoreI should support them, right? At least that's what I get from reading the Intel Ark site.

Here's what I get when I run cpupower to check governors and all that:

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

GRUB boot parameters are:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on,igfx_off i915.enable_gvt=1"

And I'm using kernel 5.15.64.

If I run powertop I don't see the C-States that most people talk about when checking power savings and idle states. Instead it only shows these

           Pkg(OS)
Powered On  0.0%
C1_ACPI    11.0%
C2_ACPI    22.9%
C3_ACPI     5.8%
RC6pp       0.0%

I checked the motherboard UEFI screen and pretty much anything that mentions power saving/power management is enabled including C-states. I have another node running an 11th gen i7 (one of those fanless units with a mobile class cpu) and it picks up the correct driver without doing anything. I also tried putting intel_pstate=force in the kernel parameters but nothing changed.

Is this normal or am I missing anything? Maybe I'm just looking in the wrong place and this is exactly what's expected.

Thanks!.

 

[dcsapak]

mmmm... can you post the output of 'dmesg' to see if it fails to load somehow?

 

[Recede9303]

mmmm... can you post the output of 'dmesg' to see if it fails to load somehow?

Will do it after work today sure!. Should I do it after a reboot to get a cleaner log or any other special setup?.

 

[Recede9303]

mmmm... can you post the output of 'dmesg' to see if it fails to load somehow?

Here's a snippet of the only line that has `pstate` or any other variation in it I could find.

I'm also attaching the whole thing. Apparently there are more errors than what I expected but can't see much related to power stuff with my limited knowledge.

❯ dmesg | grep pstate --context 20
[    0.604103] mousedev: PS/2 mouse device common for all mice
[    0.604203] rtc_cmos rtc_cmos: RTC can wake from S4
[    0.605496] rtc_cmos rtc_cmos: registered as rtc0
[    0.605808] rtc_cmos rtc_cmos: setting system clock to 2022-11-08T15:17:31 UTC (1667920651)
[    0.605820] rtc_cmos rtc_cmos: alarms up to one month, y3k, 114 bytes nvram
[    0.605825] i2c_dev: i2c /dev entries driver
[    0.606285] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[    0.606303] device-mapper: uevent: version 1.0.3
[    0.606340] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
[    0.606354] platform eisa.0: Probing EISA bus 0
[    0.606355] platform eisa.0: EISA: Cannot allocate resource for mainboard
[    0.606356] platform eisa.0: Cannot allocate resource for EISA slot 1
[    0.606357] platform eisa.0: Cannot allocate resource for EISA slot 2
[    0.606358] platform eisa.0: Cannot allocate resource for EISA slot 3
[    0.606359] platform eisa.0: Cannot allocate resource for EISA slot 4
[    0.606360] platform eisa.0: Cannot allocate resource for EISA slot 5
[    0.606361] platform eisa.0: Cannot allocate resource for EISA slot 6
[    0.606362] platform eisa.0: Cannot allocate resource for EISA slot 7
[    0.606363] platform eisa.0: Cannot allocate resource for EISA slot 8
[    0.606364] platform eisa.0: EISA: Detected 0 cards
[    0.606368] intel_pstate: Intel P-state driver initializing
[    0.607067] ledtrig-cpu: registered to indicate activity on CPUs
[    0.607085] EFI Variables Facility v0.08 2004-May-17
[    0.626778] intel_pmc_core INT33A1:00:  initialized
[    0.626822] drop_monitor: Initializing network drop monitor service
[    0.626911] NET: Registered PF_INET6 protocol family
[    1.090111] Freeing initrd memory: 59704K
[    1.094371] Segment Routing with IPv6
[    1.094395] In-situ OAM (IOAM) with IPv6
[    1.094412] NET: Registered PF_PACKET protocol family
[    1.094426] Bridge firewalling registered
[    1.094448] Key type dns_resolver registered
[    1.095141] microcode: sig=0xa0653, pf=0x2, revision=0xcc
[    1.095410] microcode: Microcode Update Driver: v2.2.
[    1.095426] IPI shorthand broadcast: enabled
[    1.095431] sched_clock: Marking stable (1086078787, 9327717)->(1126151608, -30745104)
[    1.095648] registered taskstats version 1
[    1.095984] Loading compiled-in X.509 certificates
[    1.096167] zswap: loaded using pool lzo/zbud
[    1.096637] Key type ._fscrypt registered
[    1.096639] Key type .fscrypt registered

 

[Recede9303]

Sorry for spamming messages.

I checked on my other node that has a newer (11th gen) CPU that has intel pstates working. They're both configured the same way as far as kernel and boot parameters go but while in the one that doesn't have pstates working dmesg only shows one pstate related line the other one shows two.

Node with P-States not working:

[    0.606368] intel_pstate: Intel P-state driver initializing

Node with P-States working:

[    0.763119] intel_pstate: Intel P-state driver initializing
[    0.763485] intel_pstate: HWP enabled

Doesn't tell me anything but maybe it helps troubleshooting.

 

[dcsapak]

ok dmesg look rather normal otherwise. you could try the 5.19 kernel and see if that makes a difference, also bios upgrade could make a difference here

edit: and maybe double check if the correct settings are set in the bios, e.g. enable hwp/speedshift if that setting exists

 

[Recede9303]

ok dmesg look rather normal otherwise. you could try the 5.19 kernel and see if that makes a difference, also bios upgrade could make a difference here

edit: and maybe double check if the correct settings are set in the bios, e.g. enable hwp/speedshift if that setting exists

Already tried with 5.19 and same issue. Rolledback to 5.16 because the newere one seemed to disable the ability to split the iGPU to multiple VMs.

I double checked all the power management options in the bios but yeah, I'll do it again to see if I missed anything. Will live boot Ubuntu or some other distro too to see if the same behavior happens. It will take me a couple days however so I'll report back eventually.

 

[Recede9303]

ok dmesg look rather normal otherwise. you could try the 5.19 kernel and see if that makes a difference, also bios upgrade could make a difference here

edit: and maybe double check if the correct settings are set in the bios, e.g. enable hwp/speedshift if that setting exists

Okay, did some troubleshooting today and think I solved half the issues haha.

I booted an Ubuntu and Arch live installs to see if it was a Proxmox installation/config problem and nope, it was still defaulting to the intel_cpufreq governor.I then factory reset the settings on my motherboard and... nothing. Same issue.

Here's the annoying thing though. I'm using a locked (non-K) intel CPU paired with a non-overclocking capable chipset so I was totally ignoring the Overclock section on the motherboard when checking all the options. Well, turns out that Asrock has base-clock overcloking on their "technically OC-incapable" motherboards and deep down that rabbit hole there's a setting that literally says "Disable Intel Pstates" with a default of "Yes".

Awesome.

Changed that. Booted again and yeah, now the proper driver shows up both on Proxmox and the two live images with only the powersave and performance governors available as expected.


So, that's solved. Great. But I'm still not getting the C-states to show up when I run powertop and now I'm pretty confident it has something to do with the Proxmox configuration.

When I run powertop on Proxmox it looks like this:

           Pkg(OS)
Powered On  0.0%
C1_ACPI     7.8%
C2_ACPI    24.1%
C3_ACPI    52.1%
RC6pp       0.0%

But when I tried it on the same computer but in an Ubuntu live image and an Arch one it instead read something like:

           Pkg(HW)
C2 (pc2)    1.3%
C3 (pc3)    0.0%
C6 (pc6)    0.0%
C7 (pc7)    0.0%
C8 (pc8)    0.0%
C9 (pc9)    0.0%
C10 (pc10)  0.0%

Tried with multiple kernels. Tried reducing boot options to just quiet. Same issues. Any idea what I could look into next?.

 

[dcsapak]

maybe it's just an old version of powertop that cannot read the cstates correctly?

 

[isasmendi]

Okay, did some troubleshooting today and think I solved half the issues haha.

I booted an Ubuntu and Arch live installs to see if it was a Proxmox installation/config problem and nope, it was still defaulting to the intel_cpufreq governor.I then factory reset the settings on my motherboard and... nothing. Same issue.

Here's the annoying thing though. I'm using a locked (non-K) intel CPU paired with a non-overclocking capable chipset so I was totally ignoring the Overclock section on the motherboard when checking all the options. Well, turns out that Asrock has base-clock overcloking on their "technically OC-incapable" motherboards and deep down that rabbit hole there's a setting that literally says "Disable Intel Pstates" with a default of "Yes".

Awesome.

Changed that. Booted again and yeah, now the proper driver shows up both on Proxmox and the two live images with only the powersave and performance governors available as expected.


So, that's solved. Great. But I'm still not getting the C-states to show up when I run powertop and now I'm pretty confident it has something to do with the Proxmox configuration.

When I run powertop on Proxmox it looks like this:

           Pkg(OS)
Powered On  0.0%
C1_ACPI     7.8%
C2_ACPI    24.1%
C3_ACPI    52.1%
RC6pp       0.0%

But when I tried it on the same computer but in an Ubuntu live image and an Arch one it instead read something like:

           Pkg(HW)
C2 (pc2)    1.3%
C3 (pc3)    0.0%
C6 (pc6)    0.0%
C7 (pc7)    0.0%
C8 (pc8)    0.0%
C9 (pc9)    0.0%
C10 (pc10)  0.0%

Tried with multiple kernels. Tried reducing boot options to just quiet. Same issues. Any idea what I could look into next?.

Hello all,

Any updates on this?
I've got similar setup and same issues here.I tried this solution but nothing changes
https://forum.proxmox.com/threads/c-states-not-working.72630/

I'll keep the thread posted in case I got something.
Thanks all

 

[ruezi]

Hello all,

@dcsapak : Any updates on this?

I've changed motherboard and CPU (i3 8100 -> i3 10105) and powertop doesn't show the C-States anymore

C1_ACPI, ..., PowerTop v2.11 / apt install

 

[Gabronog]

So, I have the same issue just with a newer cpu I5 11400 and an asrock motherboard (h510m-hvs) too.
I manage as the OP to get it to show up on a ubuntu live cd with powertop but when I

grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/name

grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/desc

The same output is shown C1_ACPI,C2_ACPI,C3_ACPI

 

[ruezi]

I think that version 2.11 is too old for current CPUs.
Does anyone have an idea how to install the latest version (2.14) of powertop