[Testing Update] 2022-06-03 - Linux 5.18, Systemd 251, GNOME 42.2, NVIDIA, Mesa, Pulseaudio, Perl

because amd_pstate was / is hyped.:
watch this Video on YT: René gave good informations about this new driver:

And as I understand it right its developed for notebooks (mobile) not desktop AMD CPUs.

My power states didn’t change, though hardware limits would now allow dropping clocks down to 550 MHz:

analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 550 MHz - 4.65 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 550 MHz and 4.65 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.93 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    Boost States: 0
    Total States: 3
    Pstate-P0:  3700MHz
    Pstate-P1:  2800MHz
    Pstate-P2:  2200MHz

The three states are identical with what acpi-cpufreq provides.
My AGESA version is 1.2.0.7, so the motherboard is up-to-date. CPU is 5600X
Here’s one example of 5800X from the internet:

analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 550 MHz - 4.93 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 550 MHz and 4.93 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 903 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.93 GHz.
    AMD PSTATE Nominal Performance: 128. Nominal Frequency: 3.80 GHz.
    AMD PSTATE Lowest Non-linear Performance: 59. Lowest Non-linear Frequency: 1.75 GHz.
    AMD PSTATE Lowest Performance: 19. Lowest Frequency: 550 MHz.

facing this as well I switch back to acpi-cpufreq

Just ignore the first line current CPU frequency: that is for maybe Intel?
But we have the second same line:

  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.33 GHz (asserted by call to kernel)

See: 1.33 GHz is lower than constant / standard 2,2 GHz of acpi-cpufreq in idle.
That means amd_pstate actually works.

And neofetch also shows a strange base clock of 4.6xx instead of the default when using amd_p-state.

@pheiduck and @Jaypee

I did not use neofetch

I checked KDE System Monitor that measures CPU frequencies when using idle.

Using acpi-cpufreq


Every core runs always 2,1 GHz+

VS.

Using AMD Pstate:


Every core runs 550 MHz+ that changes much flexible.

You can see both are different when using idle.

4 Likes

I’ve never used neofetch; I use watch -n1 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq, similar to what many frequency monitoring applications do.

Edit: Wow… I just noticed that that watch is causing the threads to “idle” at 2.9 Ghz instead of 550 Mhz :rofl:

Edit: Seems the states just work now(?!) (compare to my previous post)

analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 550 MHz - 4.65 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 550 MHz and 4.65 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.94 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.65 GHz.
    AMD PSTATE Nominal Performance: 132. Nominal Frequency: 3.70 GHz.
    AMD PSTATE Lowest Non-linear Performance: 62. Lowest Non-linear Frequency: 1.73 GHz.
    AMD PSTATE Lowest Performance: 20. Lowest Frequency: 550 MHz.

Sure it does. Use a compatible theme like Adw-dark. Also install the Legacy (GTK3) Theme Scheme Auto Switcher (gnome-shell-extension-legacy-theme-auto-switcher) GNOME Shell Extension and both Libadwaita and legacy applications will automatically switch themes.

That is neither necessary nor supported.

Yes

But it does not work for evolution 3.44.2-1

Why does it work for me then? Neither theme you mentioned are compatible with GNOME 42.

Are you using unstable branch?

I can reproduce this issue in testing branch: Use gnome-shell-extension-legacy-theme-auto-switcher and try to switch the dark theme Matcha-dark-aliz or other dark theme. But it shows white theme in evolution except other apps.
but the old version of evolution 3.44.1-1 has no issue.

Yes, but that makes no difference as testing and unstable are very close right now.

Again, that theme is not compatible. Use Adwaita-dark or Adw-dark and remove your GTK_THEME environment variable.

Ok, I deleted the solution. But I wonder why the current evolution still supports GTK_THEME?

Did you disable overclocking or turbo feature in BIOS setting?

I tried, but it didn’t matter. Just had to stop watching those files. :joy:

I had to do Zesko’s tip to get amd_pstate working again on kernel 5.18.

1 Like

Fps in minecraft dropped twice after update, also got some graphical bugs, reverting to stable fixed the problem, maybe some issue with graphical drivers

I noticed my PC is beeping when I reboot. Just before the computer restarts, when the desktop closes, it beeps once.

I’m at a bit of a loss which CPU frequency metric is accurate, if any…
/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq shows all cores being at 2.9 GHz or above, whether I have an active watch or just reading the text files at a single point in time.
htop gives similar results as watch -n1 grep "MHz" /proc/cpuinfo, but if I start running watch -n1 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq, htop starts to show nearly identical results to it in about a minute instead, while /proc/cpuinfo stays the same
:exploding_head:

Edit:
https://www.kernel.org/doc/html/v5.18/admin-guide/pm/cpufreq.html#policy-interface-in-sysfs

cpuinfo_cur_freq

Current frequency of the CPUs belonging to this policy as obtained from the hardware (in KHz).

This is expected to be the frequency the hardware actually runs at. If that frequency cannot be determined, this attribute should not be present.

Yup, I don’t have this option for my 5600X. So it’s guesswork, I guess? :laughing:

I guess the driver needs some more development cycles. Maybe useful on 5.19?

acpi-cpufreq is still ok for me, temps are at 30°C (idle state).