RX 7900XT clock speed does not go above ~100 MHz on Fedora 38/ Pop!_OS 22.04 LTS

joel1 · August 12, 2023, 4:54pm

Recently I swapped out my RTX 3060 Ti for an RX 7900XT. I have this unusual problem on Fedora 38 and Pop!_OS where the clock speeds appear to not be able to ramp up beyond ~5% of what they are capable of. My stress test has been Minecraft using complementary shaders (an OpenGL game). It gets about 4 fps. If I attempt to manually increase the clock speed or the fan speed in corectrl, it gets ignored. Something is locking these settings. I have installed corectrl to monitor it and the clock speed appears stuck in the range 50-100 MHz. I figured that with this card being out for about 8 months that most of the rough edges would have been smoothed out by now, but I guess I was wrong. I even tried it on fresh installs of these two distros. Does anyone else have this problem? Weirdly, it works flawlessly on OpenSUSE. I tried testing it on Manjaro but it would not boot after applying the initial updates. I will be testing it on Debian 12 shortly.

Let me know if there any command line outputs that would be useful for troubleshooting this. I am at a loss. The fact that it works on openSUSE proves that the driver and firmware support is there, but I don’t know why it refuses to work on Pop!_OS and Fedora. I tried installing the proprietary AMD drivers, but that seemed to break my fresh Fedora install. All I get is a white screen with a computer with a sad face that says “Oh no! Something has gone wrong. A problem has occurred and the system can’t recover. Please log out and try again.”

Basic machine specs:

GPU: RX 7900XT Sapphire pulse
CPU: Ryzen 9 7950X
RAM: 4x G.Skill Ripjaws 32GB
Motherboard: Gigabyte X670E Aorus Master (Bios F12)
power supply: Corsair HX1000i

update:

While trying this on Debian 12 (which also has this problem) I noticed this on the screen while it was booting into the OS:

It looks to me like it is not loading the firmware properly for some reason.

Giroud · August 12, 2023, 11:07pm

Hello, curiously i have the same problem when I set my screen at 144Hz
No problem at all if i set refresh rate to 120Hz
Someone should write a bug report for this

daveMeister · August 12, 2023, 11:51pm

It might be related to this bug:

I have been researching getting a newer Radeon card, and came across
this bug. It appears that it might be related to a firmware blob in the newest amdgpu driver.

Older kernel versions would have the memory clock stuck at max caused by incorrect vertical-blank timings for the display(s).

This one is also related to v-blank timings, but it’s a bit more complicated I believe.

There’s also this fix, which may or may not work (I haven’t tested it).

gist.github.com

https://gist.github.com/Rend0e/3bddac4285dc1f4fbe303f326f36f6cc

Fix_MCLK_Clock_Stuck_Arch_Linux_Guide.md

# Fix AMD GPU high idle power MCLK (vram / memory clock) stuck at 96 MHz / 1000 MHz for high refresh rates on Arch Linux Wayland & Xorg

On certain resolutions & refresh rates or multi-monitor setups, you might have noticed that your GPU MCLK (vram / memory clock) is stuck at the highest clock frequency (1000 MHz) [[1](https://gitlab.freedesktop.org/drm/amd/-/issues/1403)] [[2](https://gitlab.freedesktop.org/drm/amd/-/issues/2646)] causing higher GPU idle power draw.  On Linux kernel 6.4.x, AMDGPU MCLK (vram/memory) clocks at the lowest, causing major FPS drops while gaming [[1](https://gitlab.freedesktop.org/drm/amd/-/issues/2657)] [[2](https://gitlab.freedesktop.org/drm/amd/-/issues/2611)]. This is likely due to a monitor not using Coordinated Video Timings (CVT) with a low V-Blank value for the affected resolutions & refresh rates.  The higher clocking behavior is due to:

> [Well, the reason the clocks get forced to max in some cases is to avoid the flickering you are seeing.  There is a certain latency required to change the mclk.  The hardware needs to hide that mclk switch during some blanking period of the display otherwise you would see flickering.  If the blanking periods are too short or not alignable (in the case of multiple displays), the driver has to use a fixed mclk to avoid the flickering.  In your case, it appears that the latency of switching to/from the 96Mhz mclk is right on the edge of what is possible given the monitors blanking periods.  **You may need to slightly lengthen the hblank or vblank periods in your display's modeline**.](https://gitlab.freedesktop.org/drm/amd/-/issues/1403#note_1190208)

The monitor's non standard timings values were likely set that way to keep its pixel clock values within display cable bandwidth constraints that are more relevant on higher resolutions & refresh rates, which is why this issue tends to occur on high resolutions & refresh rates.

### HDMI

This file has been truncated. show original

joel1 · August 13, 2023, 12:11am

Thank you for that reference, I will look through it shortly. What puzzles me is why openSUSE appears to be an exception to this rule, despite the fact that it is running the same amdgpu version and kernel as Fedora. It also happens on Debian 12, which is using kernel 6.1. I guess for now I boot openSUSE and just never update it until this gets resolved, but I would prefer to not be limited to one distro if this never gets resolved.

joel1 · August 13, 2023, 1:02am

I can also confirm Kubuntu 23.04 also works fine. (I assume Ubuntu 23.04 would also work.)