[RESPONDED] Power-Profiles-Daemon and AMD-PState

Hi everyone,

I come to you with a load of questions ! I’ve received my Framework Laptop 13 AMD from batch 10, absolutely loving it so far !

I’ve played a bit with stress-ng (stress-ng -c 16 ) to stress my CPU and I observed the following:

  1. the CPU quickly rise to 100°C, @~4Ghz
  2. the FAN slowly catches up, taking off like a F16
  3. the CPU cool down to ~86°C, @~3,6Ghz

I’ve played a bit while with power-profiles-daemon and I discovered that it does not seem to use the amd_pstate driver.

When I run the command sudo powerprofilesctl it gives me the following:

  balanced:
    Driver:     placeholder

* power-saver:
    Driver:     placeholder

From what I’ve been able to read online, it means that PPD is using a default, low-feature driver named placeholder, since it was not able to use a platform specific driver.
On Debian, PPD’s version is 0.12-1+b1
But the pstate is installed and loaded, asserted by this two commands:

> cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences
default performance balance_performance balance_power power
> sudo cpupower frequency-info
analyse du CPU 0 :
  driver: amd-pstate-epp
  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.
  material limitation : 400 MHz - 5.13 GHz
  available governors : performance powersave
  tactique actuelle : frequency must be between 400 MHz and 5.13 GHz.
                  The powersave governor is free to choose any frequency in this interval.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.53 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    Boost States: 0
    Total States: 3
    Pstate-P0:  3300MHz
    Pstate-P1:  2200MHz
    Pstate-P2:  1600MHz

To the other FW13 AMD owners, do you have the same output ?
Is this an expected behavior as PPD do not support AMD-PSTATE yet ?

My current setup : Debian 12 with Linux framework 6.5.0-0.deb12.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.10-1~bpo12+1 (2023-11-23) x86_64 GNU/Linux.

Support for this AMD platform has been merged upstream to PPD just a few weeks ago and there is no new tagged version yet.

Have a look at this thread:

Specifically support for AMD pstate also with a platform profile has been merged upstream.

It appears you’re missing platform profile support too! This could be a bug in Debian kernel configuration or it could be too old of a version.

I suggest you clone the tree from upstream and test it. If offers both a CPU and a platform profile then there is no kernel problem. I suggest you file a bug requesting them to update to the 0.20 release after it is tagged (which should be soon).

If it’s missing a platform profile after you’ve updated there is bug that Debian kernel is missing CONFIG_AMD_PMF and I suggest you file that with them.

Thank you for your reply !

Your diagnosis was right !

I submitted the following bugreport : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063161

I’ve installed PPD from the Ubuntu PPA and I have at least support for the amd-pstate driver (should have read Framework’s doc for Linux :sweat_smile:).
That is a start !

Thanks again !

@Mario_Limonciello

It looks to me like I have a similar problem with the power profile daemon.
I am using Silverblue 39, which should actually be up to date (Framework 16 without dGPU).

From powerprofilesctl I get the following:

  performance:
    CpuDriver:	amd_pstate
    Degraded:   no

* balanced:
    CpuDriver:	amd_pstate
    PlatformDriver:	placeholder

  power-saver:
    CpuDriver:	amd_pstate
    PlatformDriver:	placeholder

powerprofilesctl version gives me:

0.20

I read around a bit, but didn’t really have a clue what might be going on or is everything ok?

You should have amd-pmf loaded. If you don’t then there is definitely something wrong.

To rule out a race condition at boot up I would suggest restarting power profiles daemon systemd unit. If it still doesn’t show up then try to load the kernel module manually.

First of all, thank you very much for your quick reply. Unfortunately, I am still more of a beginner in this area.

Do you mean with:

restarting power profiles daemon systemd unit

something like:

systemctl restart power-profiles-daemon.service

In any case, I tried it this way, but there is no change when executing powerprofilesctl afterwards.

I’m also still walking on thin ice with the kernel modules. Should I start with lsmod to check whether the module amd_pmf is available?
Anyway, I only get the following output, just pmc and no pmf:

lsmod | grep amd_pm
amd_pmc                45056  0

Sure.

Try running modinfo amd-pmf. If it doesn’t find it, then make sure you’re on the correct and latest kernel version for your distro. If you are, then there appears to be a kernel bug that it’s not built.

Hmm, modinfo amd-pmf gives me that the module is not found (also tried amd_pmf). I’m on kernel version 6.8.4-200.fc39.x86_64 which should be the latest one.

I would probably have a look tomorrow to see how I could report the kernel issue. Thank you again for your excellent service :slight_smile:

https://bugzilla.redhat.com/show_bug.cgi?id=2274069

1 Like

@Kiwi - You can boot into the 6.7 kernel, and amd-pmf should load correctly - as a temporary workaround.

If, when you reboot, grub does not show, you can either spam shift, or run the following from terminal:
# sudo grub2-editenv - unset menu_auto_hide

Mario has addressed everything here. We do not officially test against Debian, but following Mario’s suggestions are the best course forward or a kernel bug.

All right, thanks for the tip. If I find some time in the next few days, I’ll give it a try.

Oh yes, and thanks for reporting the bug, I would have had to spend a while researching how and where to do it :slight_smile:

1 Like

Thanks for opening the bugreport which I followed diligently.
Now that it appears to have been closed, I installed kernel 6.8.9-1 but the situation did not change, in fact /boot/config-6.8.9-amd64 has no traces of AMDTEE nor AMD_PMF being set.

Do you confirm that I am not missing something really obvious and that the bug was indeed not fixed (at least in the linux-signed-amd64 package)?

Did you take it from unstable repos ?
That’s weird because the commit is clear here : debian/config/amd64/config · sid · Debian kernel team / linux · GitLab

That is indeed weird. I’ve extracted the http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb and looked in the config file, just as you did and did not find it.
I’ll ask on the bug report.

1 Like

That bug report is for Fedora but I think you are trying to use a Debian kernel and those variables are not set in the stock Debian kernel (at least they aren’t in the 6.7 and 6.8 kernels). I run Debian testing and to get a kernel with AMDTEE and AMD_PMF configured, I ended up installing the linux-source package and building my own linux-image file. It’s not complicated but it takes a good while, well over an hour (not sure how long, I went out for coffee). It involves setting AMDTEE and AMD_PMF in the config file. I’d be happy to give you details if you need them. Once those options are properly configured, power consumption improved. Under my usual loads (which are not heavy), I get usage of around 6w and decent battery life.

If it’s not working even after that change linked above I think you guys should flag another bug with Debian.

If you follow the link to the original bug report by @nate_1 you’ll see it’s about Debian, and it was marked as fixed with the release of 6.8.9-1.
After the latest follow up they realized it wasn’t really fixed.

I also proceeded with a custom built kernel for the time being but am looking forward to having this fixed for good, and it looks like we’re very close.

I guess [amd64] drivers/tee: Enable TEE as module (!1088) · Merge requests · Debian kernel team / linux · GitLab fixes it then.