EDIT: The solution was that it was freesync. Turned it off on my monitor, and that fixed it.
I recently picked up a used RX 6600xt, and ever since the screen will occasionally freeze for 1-2 seconds before returning to normal. As far as I can tell, input and sound work as normal during these. There’s no real pattern either.
I’m on Mint 21.3 Cinnamon, on the 6.5 kernel (there was a sleep related issue for me in the default kernel version). Since getting the GPU, I’ve replaced the CPU and motherboard.
Any guesses as to what this might be, or where to look? I tried checking mint’s logs app and there didn’t seem to be anything associated with it.
Can
journalctlbe useful here? Does it show anything related?During the minute that one of these freezes happened, this is the log output:
Mar 30 12:14:42 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:42 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:42 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:42 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:42 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:39 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:39 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:14:06 HAL systemd[1880]: Started VTE child process 5674 launched by gnome-terminal-server process 5653. Mar 30 12:14:06 HAL systemd[1880]: Started GNOME Terminal Server. Mar 30 12:14:06 HAL dbus-daemon[1892]: [session uid=1000 pid=1892] Successfully activated service 'org.gnome.Terminal' Mar 30 12:14:06 HAL systemd[1880]: Starting GNOME Terminal Server... Mar 30 12:14:06 HAL systemd[1880]: Created slice Slice /app/org.gnome.Terminal. Mar 30 12:14:06 HAL dbus-daemon[1892]: [session uid=1000 pid=1892] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.108' (uid=1000 pid=5650 comm="/usr/bin/gnome-terminal> Mar 30 12:13:53 HAL rtkit-daemon[1238]: Supervising 12 threads of 5 processes of 1 users. Mar 30 12:13:53 HAL rtkit-daemon[1238]: Successfully made thread 5636 of process 1889 owned by '1000' RT at priority 5.Just a hunch but I’d look into rtkit. A bad process with realtime priority could starve out others.
Temporarily disable rtkit and log out.
I vaguely know rtkit handles thread/process priority… could there be any possible issues if I disable it?
Edit: actually have a more important question: how do I disable rtkit? It seems to just start up regardless of what I do.
The only important instance I know of would be your audio server (pipewire, pulse) which could also explain why audio continues to work.
how do I disable rtkit? It seems to just start up regardless of what I do.
Masking the service should do it.
My guess would be 3rd line from the bottom: a systemd service named
gnome-terminal-serveris being started. Why is it being started? Maybe it crashed and is set to always restart? Not sure.I think that was me opening the terminal to run journalctl lol
I remember there being a bug with AMD GPUs and monitors with freesync a few kernel versions ago. It’s exactly like you said, random brief freezes.
Try updating to a newer kernel or disable freesync in your monitor settings (if appplicable).
Looks like freesync was the issue - I turned off the setting in my monitor and the issue hasn’t reoccurred. Thanks for figuring that out!
Your 6.5 kernel is still quite old. I’d suggest trying a more recent kernel - there have been several AMD-related bugfixes and improvements since then, leading up to the latest stable 6.8.2. I’d also recommend upgrading to the latest Mesa, which is 24.0.4. Now whilst there are PPAs you can add to easily upgrade your Mesa, I wouldn’t recommend that option as it would introduce more instability and can cause issues with future upgrades. Instead, I’d recommend temporarily trying out a distro with a recent kernel+Mesa, such as EndeavourOS, Nobara, Bluefin etc. If you’re still experiencing issues with them, then it’s likely a hardware issue.
I would just boot Fedora and do some testing in the live environment
What cpu? If it’s a ryzen go disable ftpm in the bios settings and see if the problem goes away.
Turn off any encryption first though.
By encryption you mean disk encryption? I’m not using that so hopefully won’t have to do anything
Also I looked up that ftp
um stuttering issue and it doesn’t match with what I’m seeing. It’s not a stutter, just a complete freeze of the screen for a solid second, and then it returns to being completely normal.How sure are you that you didn’t get a card that was used for mining crypto?
Pretty sure, I got it locally on a college campus from someone upgrading their gaming PC
Check to make sure the fan on it is running fast enough (or at all). My previous card had the fan blades fall out, it happens.
Yeah the fan blades are in place, I’ve stress tested it… Don’t see how this is related to the issue at hand though.
This has already been disabled for affected amd CPUs since 6.4 and back ported to the LTS kernels
Did you mean “fTPM”?
