Screen flickering on Linux kernel 6.12

Framework Laptop 16 Linux
,
1

This is more of a heads-up for those using Framework 16 (Ryzen 7040 Series) on any linux distro (as far as I could tell). I’ve been encountering a very annoying screen flickering issue (rare horizontal stripes on the screen go in crazy colors for a fraction of a second a few times every several minutes). Very annoying, not very consistent and/or easy to reproduce.

For me, the problem occured on Arch, and later on NixOS 24.11. I also tried different compositors (picom, mutter) and desktop environments (hyprland, sway, gnome), both on Wayland and X11 – all the same. BIOS update also didn’t yield any positive results (currently I’m on the 3.05). This occurs also both with and without the discrete AMD 7700s GPU attached.

The problem started occuring roughly in November, after a system kernel update on my then-daily-driver Arch, and persisted after I switched to NixOS, on which I was using pkgs.linuxPackages_latest (which was using 6.12).

The solution was to roll back to an earlier linux kernel (currently I use pkgs.linuxPackages_6_6, but I think the issue might have started from 6.11 onward). Would be great to know if anyone else has encountered this issue, or knows if there is any open issue in the linux kernel dev community?

5 Likes
2

I’m running OpenSuse Tumbleweed with Kernel 6.12.6-1-default and XFCE4 (X11), without any graphical glitches whatsoever. So to me it doesn’t look like it’s a general problem of the kernel.

2 Likes
3

Got that same issue here. Assumed it was just the dGPU drivers, considering the dmesg output consistently contains references to amdgpu resumes.

I am on Arch with Linux 6.12.7 right now with Gnome and Wayland. Same BIOS version. I haven’t done as extensive of testing as it sounds like you have, but this does appear to happen, even with amdgpu_top reporting a suspended state on the dGPU.

1 Like
4

For me it was occurring even with the dGPU completely detached from the motherboard. So I doubt it’s hardware related. Also nothing like that occurs in Windows (as well as Linux 6.6). So I suspect this is some sort of interaction between the AMD drivers and the kernels.

1 Like
5

nice! Could you give more details pls? is this with or without dGPU? is xfce the only DE installed or do you have something with Wayland too? and what drivers have you been using?

6

I’ve been seeing this as well on Debian Trixie, with kernel 6.12.6-1, no dGPU, KDE Plasma 6 using Wayland.

1 Like
7

I think this issue reported in the Manjaro forum might be related. in the video it looks almost exactly like what I’ve been seeing, albeit not as intense. they confirm the issue started with kernel 6.11.

and found this issue on exactly framework 16, but can’t confirm whether the glitches are the same. OP provides a fix, which I haven’t yet tested.

8

That’s on the 7840 without dGPU. I’ve had problems with screen flickering on Ubuntu 22 half a year ago, running Wayland and Gnome. All monitors (internal and external) would go black for a split second before returning to normal. Switched to Tumbelweed and never looked back.
As far as I know, only X11 is active. I may have KDE and/or Gnome apps installed, including their dependencies, but the desktop environment is XFCE4.18

1 Like
9

I’ve also had some weird graphical issues, (I’m on the 6.11 kernel on fedora 40), normally it occurs the most when playing a game and the fps drops below a certain threshold, although I’ve had it happen “randomly” as well.

I’ve been following this issue on GitLab for a bit, and several people have proposed some temporary fixes (although I haven’t tried any yet)

1 Like
10

I’ve seen this on Endeavour as well (Arch based), with kernels 6.11.5 and upward.
Running 6.6 LTS is fine, and now running KDE Neon on 6.8 which is also just fine.

There’s already a similar thread here:

1 Like
11

Same issue on Debian Testing with 6.12.x, but adding amdgpu.dcdebugmask=0x10 and amdgpu.sg_display=0 to the Kernel does seem to help so far, though I haven’t tested if you need both.

12

In may case (Fedora 41) “only” add “amdgpu.dcdebugmask=0x410” do not need the sg_display.
But I do not test other config.

ps: the best to set the kernel boot param on fedora that use grubby is now.

sudo grubby --update-kernel=ALL --args=“amdgpu.dcdebugmask=0x410”
sudo grubby --info=ALL

13

I sadly can’t confirm that for my end. Glitches may have reduced, but they still show up in Firefox without.

But also it’s not impossible that there are two closely related issues that are similar in how they look, but need different solutions. At least I don’t think I’m as affected as OP described their situation. It pretty much only seems to happen in Firefox, but also it may just be more visible there, as I use Dark Reader and the glitches may just be more noticable above dark content. I’ll disable the debugmask and only enable the sg_diplay one and see what it does.

1 Like
14

Just a quick update on my end. Like I mentioned in my original post, the problem indeed was due to the linux kernel 6.10+ bug, and it did not appear in 6.6.

I recently moved back to 6.12 (pkgs.linuxPackages_latest in nixos) with an added kernel parameter "amdgpu.sg_display=0"; the problem is no longer there. Framework actually has documented the solution some time ago for Fedora.

As a sidenote, this kernel parameter disables what’s called the scatter/gather functionality and is very specific to AMD APUs (integrated chips). Turns out, this problem is not new, and people have reported issues with this as early as 2023. If interested, this article describes what this functionality means in practice.

1 Like
15

Good to know. But this is specific to a Kernel version, not to any OS. Maybe we’ll need some more generalized way of a “knowledge graph” that presents issues and their resolution/prevention in a more distro-independent way, as the same issue may land sooner or later in any distro.

Also a very interesting overview about what this parameter actually does.

16

I can confirm now, I need both Kernel flags. Only setting the sg_display one does vastly reduce the glitches, but it doesn’t fully eliminate them. Setting the debugmask seems to do the trick, at least for now.

17

Same for me actually. I initially thought sg_display was enough, but then the flickers occured albeit very rarely. debugmask basically enables/disables some of the display core functionality.

Setting debugmask = 0x410 is equivalent to enabling two separate flags (can be found here): 0x410 = 0x10 | 0x400 = DC_DISABLE_PSR | DC_DISABLE_REPLAY (| is the bitwise or operator; it’s a pretty common technique for setting flags in a C code, where you define the options with enum-s with non-overlapping bits). The documentation describes what these options mean.

DC_DISABLE_PSR
If set, disable Panel self refresh v1 and PSR-SU

DC_DISABLE_REPLAY
If set, disable Panel Replay

PSR or panel self-refresh is a functionality that allows for the refresh rate of the display to be adjusted, depending on how fast things change on the display. This is basically designed to reduce the power consumption. PSR2 (or PSR-SU, SU = selectively update) is analogous, but allows for only portions of the screen to have adjusted update frequency. Here’s a description of that:

PSR2/PSR-SU allows for expanded power-savings over the original PSR power-savings tech. Rather than being limited to power-savings when there are no changes/damage to the screen contents, this refined tech allows for selectively updating changed regions of the screen.

If I understand correctly, Panel Replay is analogous to PSR, except it’s designed for external displays (over the display port 2.0+). So I’m assuming if you’re not using an external display, simply setting debugmask=0x10 should be enough, but I haven’t tested that.

So in short, these options are intended to reduce the power consumption when rendering static (or close to static) images on the screen. Disabling them will likely increase the power consumption and shorten the battery lifespan.

1 Like
18

That’s unfortunate, PSR/PR haven’t been supported for that long, but it seems it hasn’t been ready enough yet. I hope AMD can figure out a fix either in the Kernel that can be backported to 6.12 or in firmware.

19

My girlfriend had a similar issue on her Framework Laptop 16. The issue is fixed by disabling DISPLAY_PANEL_REPLAY. So dcdebugmask=0x400 is enough. Disabling PSR as well is overkill and according to AMD people (if I interpreted stuff I read correctly) would lead to increased power usage.

1 Like
20

Interesting. I’ll check that one out too, would be great when as little as possible needs to be disabled.