[SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

entreated · 2023-06-29 00:18:37

I've been experiencing these random 1-2 second screen freezes at seemingly random times. Whenever these happen the screen is completely frozen but the computer is still working (as in the mouse and keyboard still work, audio keeps playing normally, the application/game I was on is still working and receiving input commands, etc). These freezes seem to happen in any application, although while gaming they seem to be slightly more common. They happen at random intervals, aren't exactly frequent (may happen once or twice in a 1 hour period), and would otherwise look as if the screen was paused.

I've tried observing the log of `journalctl -f` and `~/.local/share/xorg/Xorg.0.log` from a second computer connected through ssh, but nothing shows up when these happen. The video card also seems to be within nominal temperatures, no sudden spikes. I've noticed sometimes the fans spin up rapidly as soon as the screen recovers, although I think that may actually be the CPU fans (it's hard to tell).

I'm currently using the zen kernel, but I've also tried both the LTS and standard kernels, same experience. I'm currently using X11, so I'm not sure if the behaviour is the same under Wayland.

Any suggestions of where I can take a look?

My specs are:

CPU: Ryzen 9 5900X
Video Card: RX 7900 XTX
Mobo: Asus ROG Crosshair VIII Hero
DE: GNOME 44.2 on X11
Kernel: 6.3.9-zen1-1-zen

Last edited by entreated (2023-07-04 17:14:26)

seth · 2023-06-29 07:18:18

screen is completely frozen … the mouse and keyboard still work

Does the cursor still move?

To rule out an issue in the mutter compositor, do you get same freezes when running an openbox session?
Are you in the relevant admin grops, otherwise run "sudo journalctl -b" to see the system journal.

entreated · 2023-06-29 14:33:00

seth wrote:

screen is completely frozen … the mouse and keyboard still work
Does the cursor still move?

It does not.

To rule out an issue in the mutter compositor, do you get same freezes when running an openbox session?

I'd have to give a shot, but I'd need to do some tinkering as I've never used openbox before. I'll report back when I get it running.

If it turns out it's mutter, would the solution be to just use a different compositor?

Are you in the relevant admin grops, otherwise run "sudo journalctl -b" to see the system journal.

I am. Would the output change if I use it with sudo? In either case, I'm using sudo now with the second computer and checking the output.

seth · 2023-06-29 15:54:06

Gnome is essentially mutter, you cannot replace it.
However a frozen cursor suggests that it's not only the compositor - mutter may trigger it, but is not the actual problem.
If you're in either of "systemd-journal", "adm", or "wheel" you don't need to sudo journalctl to see the system journal.

entreated · 2023-06-29 18:30:49

I see.

Since you mentioned mutter, I've been running https://aur.archlinux.org/packages/mutter-performance with patch 579 only. This patch reverts a change that causes stutters in video games when using the sidekeys of a mouse. The patch removes a line described here: https://gitlab.gnome.org/GNOME/mutter/- … 525a8456a8 and the behaviour is explained here https://www.reddit.com/r/linux_gaming/c … ?context=3

While this is quite suspect, I've also tried to patch mutter manually and the behaviour seems to be the same. I haven't yet tried without patches, since the stutters make it quite unpleasant to play with. However, for the sake of testing I went and installed mutter 44.2 without patches, to see if it occurs anywhere else outside of gaming (I'm working at the moment).

I'll report back after a few hours of testing.

entreated · 2023-06-30 02:21:39

Ok, after about 5 hours it happened 2 times, once while gaming, once while doing other random stuff.

I'm not sure if switching to vanilla mutter had anything to do, but it took longer for it to show this time, at least that I could notice. I guess I have to test with openbox or some other WM to see if it happens there as well.

As usual, no errors in journalctl.

seth · 2023-06-30 05:50:50

If the cursor doesn't move, what did you mean by "mouse and keyboard still work"?
You might be runnin OOM and swapping, any significant changes in that area?
How many monitors do you use?

entreated · 2023-06-30 06:01:55

seth wrote:

If the cursor doesn't move, what did you mean by "mouse and keyboard still work"?

Both still work in the sense that whatever application is running still accepts both the keyboard and mouse input. If I press a key in the keyboard, the key is pressed in the game (e.g. a spell still fires up in the game), and if I press the left click it still executes an action (e.g. clicking over a link by mistake, it'd still open the URL).

The cursor itself doesn't move, however, it's frozen in place along with the rest of what's on screen.

seth wrote:

You might be runnin OOM and swapping, any significant changes in that area?

Not that I've noticed.

I have 64gb of RAM, and 32gb in a swapfile. I've also been observing this with htop, and both the RAM and SWAP look fine.

How many monitors do you use?

Only 1, at 3440x1440 resolution.

seth · 2023-06-30 06:18:26

The input is accepted immediately, not "replayed"?
Do you use xf86-video-amdgpu?

entreated · 2023-06-30 06:21:41

seth wrote:

The input is accepted immediately, not "replayed"?

Immediately, yes.

Do you use xf86-video-amdgpu?

I do not have that package installed. Should I?

seth · 2023-06-30 06:37:00

Usually not, but it'd be interesting to see whether you can impact this on the X11 level (notably since there're no kernel messages)

One more thing, do you use

Option "SWcursor" "True"

or was every cursor related perception limited to some "in-game" cursor (cause they don't count when we're trying to separate framebuffer from compositor)?

entreated · 2023-06-30 06:52:35

seth wrote:

One more thing, do you use
Option "SWcursor" "True"

I do not, or rather, I do not know if that's enabled. If that's something we enable manually on x11's config then I definitely haven't added it.

or was every cursor related perception limited to some "in-game" cursor (cause they don't count when we're trying to separate framebuffer from compositor)?

Yes, that'd be the case, the in-game cursor would be frozen.

I haven't quite paid attention where the cursor is positioned when the freezes occur outside of gaming, to be honest with you. I just know that one's happening cause my keyboard's input doesn't show up right away (like in the terminal or such), and then I hear the fans spin up. When I move the mouse I do not see a cursor moving at all.

seth · 2023-06-30 13:44:45

Yes, that'd be the case, the in-game cursor would be frozen.

This could be the compositor or frankly just the game, the behavior of the more regular desktop context would be a better indicator.

I just know that one's happening cause my keyboard's input doesn't show up right away (like in the terminal or such), and then I hear the fans spin up. When I move the mouse I do not see a cursor moving at all.

The GPU/graphics "freeze" might be a red herring, https://wiki.archlinux.org/title/Ryzen# … k_freezing

entreated · 2023-06-30 16:08:33

This could be the compositor or frankly just the game

It's been the same behaviour with multiple games, but I see what you're saying.

seth wrote:

The GPU/graphics "freeze" might be a red herring, https://wiki.archlinux.org/title/Ryzen# … k_freezing

Ah well. I see a few things there I could experiment with. I'm gonna keep digging and report back if any of those land on a solution or a workaround.

Thanks for the troubleshooting.

Last edited by entreated (2023-06-30 16:09:47)

entreated · 2023-07-04 07:48:32

Found the issue.

Turns out it's caused by OpenWeather, an extension for GNOME shell. It's not entirely its fault, since apparently the issue started happening in GNOME 44.x, which explains why I wasn't having issues with other distros where I am using GNOME 43.

Someone at reddit linked to this issue at gitlab, but there's not really much more info there other than a few more people describing similar problems. Disabling the extension fixes the issue for the time being.

seth · 2023-07-04 12:41:22

Gnome updates breaking extensions is unfortunately absolutely common and effectively "by design" - but freezing the video is a new one

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2023-06-29 00:18:37

[SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#2 2023-06-29 07:18:18

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#3 2023-06-29 14:33:00

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#4 2023-06-29 15:54:06

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#5 2023-06-29 18:30:49

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#6 2023-06-30 02:21:39

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#7 2023-06-30 05:50:50

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#8 2023-06-30 06:01:55

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#9 2023-06-30 06:18:26

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#10 2023-06-30 06:21:41

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#11 2023-06-30 06:37:00

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#12 2023-06-30 06:52:35

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#13 2023-06-30 13:44:45

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#14 2023-06-30 16:08:33

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#15 2023-07-04 07:48:32

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

#16 2023-07-04 12:41:22

Re: [SOLVED] Video card seems to freeze for 1-2 seconds and then recovers

Board footer