AMD gpu stop generating frames issue

Succulent of your garden · 2025-07-03 16:24:32

So, first of all, maybe this post needs to go to topics going nowhere, since I'm not providing enough information to troubleshoot my issue, yet.

I'm seeing a pattern from my gpu, an AMD 7000 xt series, when I'm starting to use the gpu more heavilty, mostly by running local LLM in my machine while surfing through the internet, my gpu stops by a second o couple of seconds to generate frames output, and then update the status, skiping the animations that should be displayed for example.

For example if I switch from a workspace to another workspace in my dwm, my screen delays the frame output a bit, until it gets updated. That's also the case when I'm writing something, the characters gets printed by a delay of seconds. I'm 100% that the problem is not the display screen, it's the gpu, because when I get down the heavy workload of the gpu, most of the time the frame delay stops.

This gpu have a very and gently coil whine, it doesn't sound to much, but when I make heavy workloads like loading and running LLMs the gpu starts sometiimes to do a coil whining. It's pretty weird because the coil whine sometimes doesn't sound, and I'm starting to think it's because of the temperature and humidity of the environment. But doing a quick research, it seems that coil whine get's worse with high temperatures, which is not the case since I'm in winter time right now.

Also when the weather is more comfy, I see that the gpu starts to stop making the whining, and usually works fine with heavy workload.

I'm not sure if this is a problem mainly for the amd drivers, because sometimes in cold environments the gpu also works fine. So what do you think ? It's because the amd drivers are not well being made or it's the weather ? I need guidance in this matter so I can be able to troubleshoot better. Not sure if it has something to do with the weather TBH.

BTW I can't post any logs, since it's not a software issue. Everything works fine at that level.

Last edited by Succulent of your garden (2025-07-07 22:00:18)

LuxFerre · 2025-07-03 16:45:10

Did you check the temperatures in the card? In some models the thermal paste degrades rather fast, then you'd need to reapply. It could be thermal throttling, although you say it's winter so less likely.

Or maybe the LLM is using all system resources? How's your ram usage?
Could also be a cable issue, I'd try a different one if possible.

The coil whine is probably normal and not meaningful, I think...

Last edited by LuxFerre (2025-07-03 16:45:50)

Succulent of your garden · 2025-07-03 19:55:04

The graphic card is quite new, and I don't think is the thermal paste. For example now my cpu is 24 °celcius, and my graphics card is 34 °. Also the graphics card present this issue from the beginning. It's pretty random to be honest, I talked this in some previous post here, I want to know if the AMD drivers can create those kind of issues. It seems that sometimes the drivers update just works and everything works fine for a well amount of time, then suddenly stops working well for a while, and then starts to work again just fine, it's very strange.

The ram usage is not a problem, I have plenty of it , but not sure now that I'm thinking about it that this is happening because I'm using the picom experimental features to use the animations. But that doesn't seems to be right, because also the typing gets laggy form the frames. I don't think that a compositor should affect the display of what I'm writing.

I tried now for example to launch the LLM and the current temperature is 50 degrees when generating tokens, and i have yet 1Gi of vram available while generating text. The moment the LLM stops writing the issues still persists, but If I killed the ollama backend process to free the vram, then everything starts to works fine without any issues instantly. This was not the case before the last month for example, everything just went very fine. Also while using the LLM and writting this text, I can confirm that the characters are being process well from my keyboard but not displayed nicely one but one, magically just everything appears in one frame.

I'm thinking seriously it's the gpu driver who is causing this issue, or at least the new version, since in some way it's pretty reproducible the bug, and I don't think picom creates the problem, since I don't think that vram freeing & picom are related in someway

Last edited by Succulent of your garden (2025-07-03 19:56:30)

V1del · 2025-07-03 21:05:48

This sounds similar to the dynamic clocking issues I've seen on 6.15, does toggling/setting power profile to high help? https://wiki.archlinux.org/title/AMDGPU … nce_levels

Succulent of your garden · 2025-07-04 21:48:56

The /sys/class/drm/ directory doesn't show a card0, but i have card1 and card2 since i have a dual gpu setup. There is a way to know which card is one ? I'm assuming is the first one card because it does have more display ports folders than the second one in the previous mentioned directory path. The second one is nvidia btw.

Also the card notice as zero in nvtop is the nvidia one, but the gpu as 1 in nvtop is the amd. But the /sys/class/drm/ is not computer science friendly and starts from one instead from zero, so not sure which one is the amd one.

If the amd is the first one, the mode is in auto, and not high.

Last edited by Succulent of your garden (2025-07-04 21:50:25)

seth · 2025-07-04 22:38:12

/sys/class/drm starts at 0 - the simpledrm device is card0 and gets deactivated when amdgpu or fbdev enabled nvidia load

tail /sys/class/drm/card*/device/vendor

Succulent of your garden · 2025-07-05 17:04:41

Thanks Seth, I manage to know which gpu is the amd one. But after updating my system everything starts to works fine. So maybe there was a bug in mesa or vulkan-radeon which affects my card only. Nevertheless the next time that this issue would happen, I will try to set the clock profile to high.

Thanks for your help everyone

Last edited by Succulent of your garden (2025-07-05 17:05:33)

Succulent of your garden · 2025-07-07 22:10:22

Hi everyone!

Today I get my session working fine a couple of hours, when then the issue starts to happen again, the frame stopping by a couple of seconds after starting to get the gpu into a hard workload by LLM usage.

I create the file in /etc/udev/rules.d/30-amdgpu-high-power.rules and made this:

  ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="high"

First of all I want to know if the initialization is correct 100% , as far I can see in /sys/class/drm/card1/device/power_dpm_force_performance_level the current performance level is in high.

But I have two questions: Is there any other way to change the performance level after reboot ? I had tried that but even with sudo echo "high" > /sys/blablabla* and i get a permission denied for trying to modify the file :c

The second question if is this going to affect in someway the gpu lifetime ? I mean is not overclocking right ? These performance levels are from factory design I imagine. But does the gpu is going to consume more watts since now is in high performance level ? or the hardware controller when the gpu is in idle is going to consume as the same in auto performance mode ?

Not sure if this gonna help, going to try now and tomorrow with this performance level, but can someone explain me in detail why the dynamic clocking issue exists ?

Last edited by Succulent of your garden (2025-07-07 22:12:20)

seth · 2025-07-07 22:23:30

even with sudo echo "high" > /sys/blablabla* and i get a permission denied

What command does that sudo and what do you need the root permissions for? (rethorical question, the "problem" shows up a lot )

The second question if is this going to affect in someway the gpu lifetime ?

More the battery one…

I mean is not overclocking right ?

No. Right.

But does the gpu is going to consume more watts since now is in high performance level ?

Generally? Yes. Absolutely? => powertop

But the primary objective is to figure whether this mitigates the problem at all.

Succulent of your garden · 2025-07-08 13:09:16

seth wrote:

The second question if is this going to affect in someway the gpu lifetime ?
More the battery one…

What do you mean with the battery ? I don't think is the cmos battery right ?

seth wrote:

me wrote:
But does the gpu is going to consume more watts since now is in high performance level ?
Generally? Yes. Absolutely? => powertop

TY

set wrote:

But the primary objective is to figure whether this mitigates the problem at all.

I'm into that, i'm going to see in the coming days if that's the case. But I really wonder why is this happening ? I mean Nvidia have some similar issue right now ? I just don't think it was because I changed the /sys/blablabla [just joking to seth here ]

Last edited by Succulent of your garden (2025-07-08 13:10:10)

seth · 2025-07-08 14:57:45

If this is a notebook, your on-battery runtime will suffer.

But I really wonder why is this happening ?

See V1del's comment - likely known bug/regression in 6.15

I mean Nvidia have some similar issue right now ?

I just don't think it was because I changed the /sys/blablabla

lokcking in power_dpm_force_performance_level will actually prevent the problem because the GPU cannot fail to step up if it won#t step up because it's running full steam anyway.
Did you figure why your echo won't work?

Succulent of your garden · 2025-07-08 16:42:50

seth wrote:

If this is a notebook, your on-battery runtime will suffer.

Ah I see, no this is a tower pc

seth wrote:

See V1del's comment - likely known bug/regression in 6.15

I get it now, its about the kernel right ? I'm currently running Linux 6.12.35-1-lts btw, so maybe it's far more back :C

seth wrote:

copium

Thanks. Now the joke: Just going to wait until I get one gpu from the rtx 5000 series, and then create the continuation of this post: Hey my psu gpu cable just melt

seth wrote:

Did you figure why your echo won't work?

Not yet

seth wrote:

lokcking in power_dpm_force_performance_level will actually prevent the problem because the GPU cannot fail to step up if it won#t step up because it's running full steam anyway.

Sadly, I must say that even with the high power mode it's still creating the issue. Today was working right, until now. But I must say that using the high performance setup the gpu seems to stay less time without printing the frames.

what do you think about using the picom animations ? https://picom.app/#_animations I'm using the experimental features, but i'm using the default picom from arch, not a fork. Not sure if this is causing the problem, since sometimes this computer just works well. Do you think is fine to start to disable the animations to troubleshoot ?

EDIT: Today the gpu with high perfomrance mode works most of the time worse or equally than yesterday with auto performance mode :C

Last edited by Succulent of your garden (2025-07-08 20:36:44)

seth · 2025-07-08 21:44:39

I'm currently running Linux 6.12.35-1-lts btw

Idk whether the problem has been backported, you might want to try some 6.14 kernel.
Though

must say that even with the high power mode it's still creating the issue

seems it's not that.

what do you think about using the picom animations ?

fancy

Do you think is fine to start to disable the animations to troubleshoot ?

I'd start troubleshooting by killing picom…

--- OT:

Not yet :hmm:

sudo echo foo > somewhere

There's sudo, a command, a redirection and a file.
What does sudo elevate, the command or the redirection?
What needs the elevation? echo? Can't you "echo foo" w/o sudo?
"man tee"

Succulent of your garden · 2025-07-09 14:22:55

seth wrote:

I'd start troubleshooting by killing picom…

Now I'm using the card and everything is going fine, with the high performance setup. I'm going to shut down my wm and start again with my picom line in xinitrc commented when the problem starts again , going to see if that helps. But right now everything seems fine, which is weird, I just updated the system today btw again.

seth wrote:

There's sudo, a command, a redirection and a file.
What does sudo elevate, the command or the redirection?
What needs the elevation? echo? Can't you "echo foo" w/o sudo?
"man tee"

echo "auto" | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level
 #does the work :) , thanks for the help in noticing that :P

seth wrote:

Idk whether the problem has been backported, you might want to try some 6.14 kernel.

Going to try that, after I saw that picom is not the problem I'll let you know when I have new information about this.

Last edited by Succulent of your garden (2025-07-09 14:29:02)

Arch Linux

#1 2025-07-03 16:24:32

AMD gpu stop generating frames issue

#2 2025-07-03 16:45:10

Re: AMD gpu stop generating frames issue

#3 2025-07-03 19:55:04

Re: AMD gpu stop generating frames issue

#4 2025-07-03 21:05:48

Re: AMD gpu stop generating frames issue

#5 2025-07-04 21:48:56

Re: AMD gpu stop generating frames issue

#6 2025-07-04 22:38:12

Re: AMD gpu stop generating frames issue

#7 2025-07-05 17:04:41

Re: AMD gpu stop generating frames issue

#8 2025-07-07 22:10:22

Re: AMD gpu stop generating frames issue

#9 2025-07-07 22:23:30

Re: AMD gpu stop generating frames issue

#10 2025-07-08 13:09:16

Re: AMD gpu stop generating frames issue

#11 2025-07-08 14:57:45

Re: AMD gpu stop generating frames issue

#12 2025-07-08 16:42:50

Re: AMD gpu stop generating frames issue

#13 2025-07-08 21:44:39

Re: AMD gpu stop generating frames issue

#14 2025-07-09 14:22:55

Re: AMD gpu stop generating frames issue

Board footer