Micro stutters with Ubuntu 26.04 lts on AMD hardware

Ubuntu Version: 26.04 LTS

Desktop Environment: GNOME

Problem Description:
Hi Guys, i suffer from short, recurring micro stutters. Every so often the rendered image freezes for a split second and then jumps to catch up. the mouse cursor hitches, and in videos the picture freezes while the audio keeps playing normally. It is not a full system hang, only the display output stalls. It also happens on a bare desktop with no video playing, so it is not tied to a player or browser (tested with Firefox and Helium) it behaves like the compositor is dropping frames.

Reproduce: run the desktop at 180Hz and just use it normally (move the cursor, scroll, play a video). The stutter shows up at random intervals, every few minutes.

Key detail: on the exact same machine, Windows 11 is perfectly smooth, and Fedora 44 with KDE/KWin is also smooth at 180Hz (comparison only). The problem appears only on Ubuntu 26.04 with GNOME. I would love a fix or a workaround that lets me stay on Ubuntu 26.04 because besides that im very happy :slight_smile:

Relevant System Information:

Mini-PC: Arcitc Senza AI 370
CPU/GPU: AMD Ryzen AI 9 HX 370 / Radeon 890M 
RAM:     32 GB LPDDR5
Kernel:  7.0.0-22-generic
Mesa:    26.0.3 (radeonsi, strix1, ACO)
Session: GNOME on Wayland
Display: single 27" 1440p @ 180Hz, 100% scaling, VRR off
Install: fresh, fully updated

Screenshots or Error Messages:
No errors so gar, the relevant logs are clean (at least the ones i knew), and nothing is logged at the moment a stutter happens:

journalctl -b -k | grep -iE "amdgpu|drm|gpu reset|fence|page fault|timeout"

-- only normal driver init, no errors/timeouts/resets

sudo dmesg -w

-- nothing appears at the instant of a stutter

journalctl -b -u bolt

-- clean, no thnderbolt timeouts

What Ive Tried:

  • Disabled C-states and turbo in UEFI. no change
  • VRR/FreeSync off; scaling at 100% (no fractional scaling); mutter experimental-features cleared
  • Checked power_dpm_force_performance_level (= auto)
  • Ruled out video decode, it happens with no video playing at all
  • Ruled out hardware. Windows 11 and Fedora 44 KDE are both smooth on the same box

Before Posting:
I searched for existing reports of micro-stutter on Strix Point / RDNA 3.5 under GNOME Wayland and did not find a matching solved thread.

has anyone seen this on Ubuntu at high, and is there a known workaround or fix for it?

I appreciate your help and input :slight_smile:

3 Likes

Welcome to the Ubuntu Discourse!

Your issue sounds awfully reminiscent of this one:

Any luck with that workaround?

What a well-written and researched report, BTW! :clap:

3 Likes

Welcome to the Ubuntu Discourse @minze90

Your report already rules out many of the usual explanations, which makes this particularly interesting. A few things stand out:

  • The issue only appears on Ubuntu 26.04 with GNOME, while the same hardware runs smoothly under Windows 11 and Fedora/KWin.
  • There are no amdgpu resets, fence errors, page faults or timeout messages in the logs, even while the stutters occur.
  • The symptoms point more towards a display pipeline or compositor-related problem than a full GPU failure, especially since audio continues normally and the entire system remains responsive.

Given that this is very recent AMD hardware running at 180 Hz, I would keep an eye on newer kernel and Mesa updates, as these kinds of intermittent frame pacing issues often improve as support for new platforms matures. At the moment, this doesn’t look like a hardware fault to me. It feels more like a software interaction specific to Ubuntu’s GNOME stack on Strix Point systems. If others with similar hardware can reproduce the behaviour under the same conditions, that would help narrow down whether this is a Mutter issue, a kernel regression, or something in the display stack affecting high refresh rate workloads.

2 Likes

I think this is it. Installing the proposed kernel should fix it. Worked for me, at least.

3 Likes

UPDATE: Solved! :slight_smile:

Thanks a lot for the quick help, especially @yasirel for linking the launchpad!

What fixed it for me was installing the kernel from proposed 7.0.0-26. For anyone else landing here from a search, heres the short version:

  1. Enable the proposed pocket (official guide: https://documentation.ubuntu.com/project/SRU/reference/enable-proposed/). Quick way on 26.04:
sudo tee /etc/apt/sources.list.d/ubuntu-proposed.sources >/dev/null <<'EOF'
Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: resolute-proposed
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
EOF

sudo tee /etc/apt/preferences.d/proposed-pin >/dev/null <<'EOF'
Package: *
Pin: release a=resolute-proposed
Pin-Priority: 400
EOF
2.Install the kernel:
sudo apt update
sudo apt install -t resolute-proposed linux-generic
  1. Reboot, and check with uname -r.

perfectly smooth now, no more freezes for me :slight_smile:

Marking this as solved. Thanks again guys <3

2 Likes

Just make sure to disable proposed again, it is the testing ground for all archive packages and often enough has broken ones that get pulled back before reaching the actual archive…

1 Like

FYI, you probably shouldn’t change the default priority of the proposed pocket in such a generic way, not anymore since the 24.04 release at least. It is already configured like backports (Pin-Priority: 100), which never install automatically but can be installed by temporarily changing the target release with -t switch of apt; any proposed packages that are already installed will be upgraded nonetheless, just like backports.

That should probably be a more targeted command to only get the linux-image-7.0.0-26-generic package installed. That way there can be no accidental upgrade to even newer proposed versions of linux-generic; eventually the latter (still tracking main) will just overtake the then aged out version from proposed.

2 Likes

thanks for the info! so that should fix it for me or am i wrong?

sudo rm /etc/apt/preferences.d/proposed-pin
sudo rm /etc/apt/sources.list.d/ubuntu-proposed.sources
sudo apt update

If you run that after having installed said kernel, yes; but you also don’t really have to, thanks to that change of how the proposed pocket is implemented now, unless I’m missing something, @ogra.

It used to be that proposed would just end up with priority 500, which is the default for all packages in Ubuntu — APT::Default-Release is not defined — and thus the newer versions of all packages in that pocket would always win and APT consequently upgrading to those — the all or nothing conundrum mentioned in the release announcment. But, since it’s like backports now, which has NotAutomatic: yes and ButAutomaticUpgrades: yes in the Release file (see apt_preferences(5)), the priority is automatically set to 100. You can check by running apt policy without further arguments.

To summarize, I’d install linux-image-7.0.0-26-generic directly, without touching linux-generic; downgrade it, if you already have: sudo apt -t resolute install linux-generic should downgrade it, so it won’t track proposed anymore. That would mark that particular kernel image as manually installed, which handily prevents it from being auto-removed. At some point linux-generic will probably simply depend on that version, when it has trickled down, bar any pullbacks. You can then just

apt-mark auto linux-image-7.0.0-26-generic

and leave the rest to APT and the kernel cleanup scripts, which harvest older kernels to only leave the latest and the one installed before that. :smiling_face_with_sunglasses: :beach_with_umbrella:

1 Like

Nope, you are correct, I’m still living in the past :slight_smile:

Using apt install -t … as you described it should work in newer releases …

1 Like

This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.