Graphical Corruption in Fedora 41 on AMD (BIOS3.06, Linux 6.13.5)

Framework Laptop 13 Linux
21

Fantastic, does this also apply to the other components in the mesa-* packages?

22

Is there an existing/open Mesa issue for this?

23

I donā€™t think so. On the other hand, I donā€™t know where/how to report.

24

As another datapoint Iā€™m also experiencing this corruption. Iā€™m testing the proposed workaround now.

25

Just also offering a count of this issue.

In my case, rolling back mesa-va-drivers to mesa-24.2.4-1.fc41.src.rpm actually did not fix the graphical corruption (when using external monitors.) In the next few days Iā€™ll try to troubleshoot this further, but my specs are similar to what is seen in this thread. (to quote variegated.vanilla):

DNF Package Version Installed
kernel.x86_64 6.13.5-200.fc41
amd-gpu-firmware.noarch 20241210-1.fc41
amd-ucode-firmware.noarch 20241210-1.fc41
mesa-va-drivers.x86_64 24.2.4-1.fc41
26

After a few days, it looks like downgrading and version locking that downgrade as noted in has successfully worked around the issue for me.

27

I had the same issue, so back here to share my solution:
My Framework 13 AMD on fedora had some annoying graphical artifacts that were a known issue by then (dec 2023). I therefore used the solution provided in the guides and added a kernel flag:

sudo grubby --update-kernel=ALL --args="amdgpu.sg_display=0"

After upgrading to kernel 6.13 the artifacts were back. After I removed the flags (so back to default) the artifacts were gone.

sudo grubby --update-kernel=ALL --remove-args="amdgpu.sg_display=0"
8 Likes
28

Looks like the recent Fedora upgrades I installed yesterday fixed this for me. No more weird pixel squares. So you may want to try if you can go back to the current version.

29

Can confirm, I had the same problem on Arch, (mesa 25, kernel 6.13); removing the kernel parameter fixed it for me.

30

Thank you. I had the same problem and this seems to have solved the issue in my case.

1 Like
31

The other mesa packages have a dependency relationship with mesa-va-drivers, so locking just that one is sufficient to lock all of the mesa-* packages, without having to type all of them.

32

Augh! I canā€™t wait on a fix anymore. My laptop has been a paperweight for over 2 weeks now. Can barely even use it to read text on the internet before it starts glitching. :frowning: Iā€™ve never downgraded a dnf package before. When I try to do sudo dnf downgrade mesa-va-drivers-0:24.2.4-1.fc41.x86_64 it just tells me ā€œPackages for argument ā€˜mesa-va-driversā€™ available, but not installedā€. How is this supposed to work?

edit: Apparently I just needed to keep banging my head against this for another 10 minutes. I have RPM Fusion enabled to get video acceleration, and that package is named mesa-va-drivers-freeworld instead.

33

Hi Scott! You might also check if you have the kernel parameter for amdgpu.sg_display=0 enabled (see further up this thread). Iā€™ve been able to resolve my Fedora 41 crashes while also letting Mesa upgrade freely by removing that configuration. Itā€™s only been a few days, but so far it seems solved for me.

1 Like
34

Iā€™ve just started having this problem to. Going to try removing the amdgpu.sg_display=0, wish me luck.

Update
Seems that fixed it, thanks @Erik_Drenth Iā€™ll have to keep my eyes out and see if it crops up again. Minecraft seems to trigger it for some reason.

1 Like
35

Thanks! This was my issue as well.

36

Not sure if itā€™s just me, Iā€™m still seeing this on the latest Fedora 42 :frowning:
Already removed the amdgpu.sg_display=0 thing and downgrading to mesa-va-drivers-0:24.2.4-1.fc41.x86_64 no longer seems to be an option.

37

Hrm. I was about to ask if itā€™s been fixed in 42. I guess I wonā€™t be upgrading for a while yetā€¦ Bummer.

38

This is also preventing me from upgrading to Fedora 42. A bit disappointing for an officially supported distro.

@Matt_Hartley Is there anything that can be done to accelerate fixing this issue?

39

For others like me, Scott, and Imran who are unable to find old versions of mesa-va-drivers in the Fedora 42 repositories, you can find old versions of the packages in the Koji build system, and install them manually using dnf.

From the Gitlab issue, it seems that the last version without the bug is 24.3.4.

  1. Find the build on Koji (link).
  2. Download the files into a directory, either from the link above or using the koji CLI, eg:
    mkdir temp-mesa-fix
cd temp-mesa-fix
koji download-build --arch=x86_64 mesa-24.3.4-1.fc42
sudo dnf downgrade *.rpm
    Note: although the download includes a ton of other mesa-related rpms, dnf downgrade will skip any that arenā€™t already installed on your system, so using *.dnf should be safe.
  3. After completing the download, pin mesa-va-drivers to the safe version to prevent accidentally updating it during normal system updates:
    sudo dnf versionlock add mesa-va-drivers
    When you run updates, mesa-* packages will still appear in the update list. However, when you actually run the update, versionlock will prevent them from being updated, and dnf should prevent dependency conflicts.

Later, when the bug is fixed, you can unlock the package with dnf versionlock delete mesa-va-drivers

40

I sadly have disabled my system by upgrading to 42ā€¦