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.

    • Julian@lemm.eeOPEnglish
      5·
      9 months ago

      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.
      • Atemu@lemmy.ml
        4·
        9 months ago

        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.

        • Julian@lemm.eeOPEnglish
          4·
          9 months ago

          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.

          • Atemu@lemmy.ml
            2·
            9 months ago

            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.

      • F04118F@feddit.nl
        3·
        9 months ago

        My guess would be 3rd line from the bottom: a systemd service named gnome-terminal-server is being started. Why is it being started? Maybe it crashed and is set to always restart? Not sure.

        • Julian@lemm.eeOPEnglish
          4·
          9 months ago

          I think that was me opening the terminal to run journalctl lol

  • atmur@lemmy.worldEnglish
    6·
    9 months ago

    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).

    • Julian@lemm.eeOPEnglish
      2·
      9 months ago

      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!

  • d3Xt3r@lemmy.nzM
    5·
    9 months ago

    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.

  • db2@lemmy.world
    1·
    9 months ago

    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.

    • Julian@lemm.eeOPEnglish
      2·
      9 months ago

      By encryption you mean disk encryption? I’m not using that so hopefully won’t have to do anything

      Also I looked up that ftpum 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.

      • db2@lemmy.world
        1·
        9 months ago

        How sure are you that you didn’t get a card that was used for mining crypto?

        • Julian@lemm.eeOPEnglish
          1·
          9 months ago

          Pretty sure, I got it locally on a college campus from someone upgrading their gaming PC

          • db2@lemmy.world
            1·
            9 months ago

            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.

            • Julian@lemm.eeOPEnglish
              1·
              9 months ago

              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.