6.4 kernel mclk stuck at lowest on rx 6900 xt

When I updated to linux kernel 6.4 my amd gpu rx 6900 xt is now stuck at 96 mhz mlck. Before it was always at max mhz which is 1000, at least the bug with the high power consumption with 4k 120hz screen is fixed but now it never goes higher than 96 mhz which means my games run now with lower peformance.

I already tried to manually set the mclk frequency to 1000mhz by using pp_dpm_mclk and setting it to 3 aswell setting power_dpm_force_performance_level to manual.

Downgrading the Linux kernel back to 6.3.9 forces MCLK at max frequency again.

GPU: XFX Speedster merc rx 6900 xt CPU: Ryzen 7 3700X GPU Driver: Mesa 23.2-devel OS: Arch Linux

Can you bisect?

ill see about it, i dont know which commit caused this ill just go through the changelogs on the latest kernel and let you know which one changed power management

there's a variety of commits that changed mclk handling behavior such as ef3d74aa7e5d ("drm/amd/display: Add missing mclk update") and a series of commits that reversed mclk handling for APUs (like f1373a97a41f ("drm/amd/pm: reverse mclk and fclk clocks levels for yellow carp")). Those shouldn't be it but there are also changes that went in for subvp.

IOW it might not be straightforward to tell from just git commits. A proper kernel bisect would be ideal .

after compiling over and over (and wasting power) I've finally found the culprit, it's 6.4.0-rc5. Some commit from 6.4.0-rc4 to 6.4.0-rc5 has changed something for mclk.

I hope you can start something with this info

EDIT: it must be one of those: Tim Huang (5): drm/amd/pm: reverse mclk and fclk clocks levels for SMU v13.0.4 drm/amd/pm: reverse mclk clocks levels for SMU v13.0.5 drm/amd/pm: reverse mclk and fclk clocks levels for yellow carp drm/amd/pm: reverse mclk and fclk clocks levels for vangogh drm/amd/pm: reverse mclk and fclk clocks levels for renoir

in amdgpu, these are the changes between 6.4-rc4 and 6.4-rc5:

663b930e24842 drm/amdgpu: enable tmz by default for GC 11.0.1
e490d60a2f76b drm/amd/pm: resolve reboot exception for si oland
bc3e1d60f933f drm/amdgpu: add RAS POISON interrupt funcs for jpeg_v4_0
30b2d778f629d drm/amdgpu: add RAS POISON interrupt funcs for jpeg_v2_6
ce784421a3e15 drm/amdgpu: separate ras irq from jpeg instance irq for UVD_POISON
020c76d983151 drm/amdgpu: add RAS POISON interrupt funcs for vcn_v4_0
6889f28c736c3 drm/amdgpu: add RAS POISON interrupt funcs for vcn_v2_6
ac1d8e2f074d9 drm/amdgpu: separate ras irq from vcn instance irq for UVD_POISON
8e1b45c578b79 Revert "drm/amd/display: Do not set drr on pipe commit"
c14fb01c4629b Revert "drm/amd/display: Block optimize on consecutive FAMS enables"
55e02c14f9b5f drm/amd/pm: reverse mclk and fclk clocks levels for renoir
bfc03568d9d81 drm/amd/pm: reverse mclk and fclk clocks levels for vangogh
f1373a97a41f4 drm/amd/pm: reverse mclk and fclk clocks levels for yellow carp
c1d35412b3e82 drm/amd/pm: reverse mclk clocks levels for SMU v13.0.5
6a07826f2057b drm/amd/pm: reverse mclk and fclk clocks levels for SMU v13.0.4

The reversing mclk/fclk levels shouldn't be it because those are for other GPU products than yours. I would suspect it's one of those two reverts. Can you confirm which one?

I'm recompiling now after i reversed both commits, I'll get back to you in a bit

Okay, it finished compiling but it still shows 96MHz and not 1000Mhz even after reversing both commits (6a07826f2057b & c1d35412b3e82). What can I do?

I think run git bisect on the drivers/gpu/drm/amd directory between those two tags to confirm which one it is.

I tried to bisect with the same GPU, but there seems to have been a prior commit that completely broke freesync (logging into a wayland session that enabled freesync would crash amdgpu and result in my monitor no longer detecting DP input). Not even rc4 works for me. So I wasn't able to find the first bad commit.

But assuming rc4 works for you and doesn't have the mclk problem, maybe this will help a little bit? (my git bisect log with minor comments)

bad: [9561de3a55bed6bdd44a12820ba81ec416e705a7] Linux 6.4-rc5 -- mclk problem
bad: [663b930e24842f3d3bb79418bb5cd8d01b40c559] drm/amdgpu: enable tmz by default for GC 11.0.1 -- mclk problem
bad: [8e1b45c578b799510f9a01a9745a737e74f43cb1] Revert "drm/amd/display: Do not set drr on pipe commit" -- mclk problem
skip: [f1373a97a41f429e0095d4be388092ffa3c1a157] drm/amd/pm: reverse mclk and fclk clocks levels for yellow carp -- monitor disconnect
skip: [bfc03568d9d81332382c73a1985a90c4506bd36c] drm/amd/pm: reverse mclk and fclk clocks levels for vangogh -- monitor disconnect
skip: [c1d35412b3e826ae8119e3fb5f51dd0fa5b6b567] drm/amd/pm: reverse mclk clocks levels for SMU v13.0.5 -- monitor disconnect
skip: [55e02c14f9b5fd973ba32a16a715baa42617f9c6] drm/amd/pm: reverse mclk and fclk clocks levels for renoir -- monitor disconnect
skip: [6a07826f2057b5fa1c479ba56460195882464270] drm/amd/pm: reverse mclk and fclk clocks levels for SMU v13.0.4 -- monitor disconnect
skip: [c14fb01c4629b96b64ab54caea7e543a0239f14e] Revert "drm/amd/display: Block optimize on consecutive FAMS enables" -- monitor disconnect

added 6000 dGPU Series label

changed the description

Does the mclk increase when there is GPU load (e.g., when running a game)? There were a number of display fixes in 6.4 to be able to keep the mclk low when the GPU load is low.

No, game performance is pretty much halfed since mclk is stuck at 96 MHz. I use doom eternal to test

I can confirm this issue on rx 6700xt too. Initially i thought this was due to some custom kernel issue but every "flavor" i tested behaves the same.

I also saw a low power usage when using corectrl to lower core clocks or doing anything except for fan control.

And to answer @agd5f here, for me it doesn't change at all no matter the load.

EDIT: Also tried different power modes compute,VR etc but it doesnt change the memory clock.

Running kde x11 with freesync 1080p 165hz but will test different setups shortly

EDIT2: Disabling freesync fixes the issue but results in 30w on idle instead of 25w as was in 6.3 with freesync on.

What display modes are you using? Does changing the modes on the monitors change the behavior?

After disabling freesync the clock went right to 1000mhz.

Power usage also increased from 8w with freesync to 30 which is 5w higher than on 6.3 with freesync. (edited)

Games run fine now

Same here, after disabling freesync mines now also runs at 1000mhz again. de: KDE with wayland resolution: 4k 120hz

added DC label

Can confirm this issue also happens on 7000 series too. I have a 7900XT and MCLK is locked at 96Mhz regardless of VRR. And this happens both on kwin and hyprland(wlroots). The issue persists at 6.4.1

And a workaround will be set monitor frequency to 90hz if supported, or if on a wlroots-based compositor, set the monitor frequency to something slightly off like 143hz will also work.

Can confirm the same problem on a 6600XT with Linux 6.4.1. Disabling Freesync works.

Have same problem with Gigabyte AMD 6700XT. I have monitor with 165 refresh rate. When I use 90Hz refresh i dont have any problems with GPU power(185 Watt). When I set refresh rate >90HZ (100,120,144,165) my GPU use only 65 Watt max and MEM 96 MHz.

Mainboard: MSI PRO B650-P WIFI CPU: Ryzen 7600X GPU: Radeon RX 6700XT 12Gb Display: Xiaomi Mi Gaming 27 with DisplayPort connection.

Kernel 6.4.1 mesa 23.1.3 Wayland 1.22.0 GNOME 44 EndeavourOS

Same issue at 6.5.rc4

Similar to @MarkGhanz, the mclk of my 7900XT is stuck at 96MHz regardless of whether VRR is enabled.

I tried forcing the mclk through the commands:

echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "3" >  /sys/class/drm/card0/device/pp_dpm_mclk

but the mclk remains stuck at 96MHz unless after commands are applied, I change the refresh rate or display resolution (to any arbitrary refresh rate or resolution). Only then will the forced mclk be in effect. The forced mclk will remain in effect even if I subsequently revert back to the original refresh rate.

Kernel 6.4.1, Mesa 23.1.3, Arch Linux, KDE Plasma 5.27.6 (Wayland).

Two more things to add:

1. The mclk was stuck at 96MHz even in video games.
2. The sclk does not seem to have issues. It manages to downclock at idle and reach max frequency in games as expected.

Is it the same issue as #2611 (closed)?

Probably I think. My workaround was also changing the monitor ref rate to something lower. Even just 1hz lower make the mclk works as intended. According to RTINGS my monitor could reach 160hz given VRR enabled if connected through HDMI 2.1. I can test the same trick by setting the ref rate to something like 159hz after I have a certified cable.

Supposedly some commit in amd drm next repo fixes it:

Good news: It's fixed with tag amd-drm-next-6.5-2023-06-16 , VRAM correctly clocks up and down with 165Hz. Will close once fix is in mainline / stable.

So I wonder which one and can it be applied to 6.4.1 to test.

I just tested it with 7900 XTX and 6.4.1 (180 Hz monitor, adaptive sync active, using DisplayPort). MCLK reclocks fine for me when playing Cyberpunk 2077. KDE Plasma 5.27.5, Wayland session.

We still don't know which patch caused it and which patch in drm-next fixes it, right... ?

From testing conducted on https://bbs.archlinux.org/viewtopic.php?pid=2108244#p2108244 The causal commit is 8e1b45c578b79 as 6.4.1 with only that commit reverted resolved the issue.

@loqs I can confirm that agd5f/linux@8e1b45c5 is the commit that's causing my low mclk issue.

However, if I go one commit before that: agd5f/linux@c14fb01c, my 7900 XT's mclk is locked at the highest frequency. I did some preliminary testing and narrowed it down to a commit between amd-drm-next-2023-04-14 and amd-drm-fixes-6.4-2023-04-26 that's causing it.

Found the high mclk causing commit: agd5f/linux@822b84ec

Edit: To clarify, prior to this commit, my RX 7900XT running at 3840x1600@144Hz (no VRR) can downclock to 456MHz (1 step above the lowest 96MHz) at idle.

added bisected label

mentioned in issue #1500 (closed)

Can confirm the MCLK of my 6600XT doesn't go above 96 MHz when I switch to 120 Hz in Cinnamon's display settings. I get much lower FPS in CS:GO Zombie Escape mode (64 players, custom maps). +fps_max 120 in Steam's launch options, but these FPS are never reached now, instead the FPS are like 20-40 now.

Workaround: Switch to 100 Hz for a few minutes and then back to 120 Hz.

Rest of the hardware: S95B OLED TV running at 3840x2160,5600X,16GB RAM,Arch with latest updates: linux 6.4.7.arch1-1,cinnamon 5.8.4-1 and linux-firmware 20230625.ee91452d-5.

Slightly off topic, but could I know how did you get 120Hz working over HDMI? It seems HDMI 2.1 doesn't work on open source kernel modules now.

@MarkGhanz He might've tried with a lower than 4K resolution, such as 1080p@120hz, for example.

@MarkGhanz It works for me, 4k 120Hz as well drm_info tells me that I use 10 bpc. Maybe your GPU can't properly get the EDID file?

@pure5665 I don't see how that is possible with HDMI 2.0 speeds.
This calculator and Wikipedia tells me it's impossible, even at 4:2:0 chroma subsampling.

https://www.murideo.com/hdmi-21-bandwidth-calculator.html
https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_HDR10_video

@nfp0 I don't use HDMI 2.0 though but HDMI 2.1. I plugged in my HDMI cable to a 2.0 port, now i can't use 120HZ anymore but bpc is still at 10. So HDMI 2.1 definitely works for me with 4k and 120HZ.

@pure5665 But amdgpu does not support the HDMI 2.1 FRL feature, necessary to do 4K@120hz@10bit, as seen here: #1417

How did you achieve that?

@nfp0 It just works for me, contact me on Discord maybe i can give you edid files or whatever you need to reach the same Pure™# 0087

For anyone following this, we were not able to achieve 4K@120hz@10bpc. The TV was only receiving ycbcr 4:2:0 at 8 bits, which conforms to HDMI 2.0 speeds.

@MarkGhanz The 120 Hz are at 4:2:0 chroma subsampling, since #1417 is still unfixed. For bandwidth calculation see #1417 (comment 2007543).

I just tried the current tip of the drm-next branch and it appears the issue has been fixed, at least for my RX 7900 XT running resolution 3840x1600@144Hz (no VRR).

Frequency downclocks to 96MHz at idle and goes up to max during games. There doesn't appear to be any flickering or performance issues, but I haven't had time to run a long gaming session to truly "stress test" it.

Tried 6.5-rc2, mclk is still stuck at 96MHz on 7900XTX 3440x1440@144Hz (with or without VRR).

I didn't look in detail what has been merged but seems what fixed it in drm-next is not yet in 6.5

@OnlyLys @sebcaty Which distro do you guys use to freely upgrade/downgrade/revert commits for pkgs?

I compiled the kernel from source, either from https://gitlab.freedesktop.org/agd5f/linux to test AMD's fixes or from Linus's mainline kernel tree when I want to test some release candidate kernel version.

But to answer your question, my distro is Arch Linux.

I can confirm the same issue and workarounds as mentioned in this thread with an RX6700 (non-xt) using any 6.4 or 6.5 branch currently. I have reverted to LTS in the meantime and it works just fine.

It took me hours to find this bug report as I debugged my issue, as I focused on another element that seems to be present, though it might be just because of the mclk (for me, I noticed the card was "stuck" on 50w power limit, but I think it's actually the mclk mentioned, it just doesn't need more than 50w to produce that clock).

mentioned in issue #2708 (closed)