Fantastic, does this also apply to the other components in the mesa-* packages?
Is there an existing/open Mesa issue for this?
I don’t think so. On the other hand, I don’t know where/how to report.
As another datapoint I’m also experiencing this corruption. I’m testing the proposed workaround now.
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 |
After a few days, it looks like downgrading and version locking that downgrade as noted in has successfully worked around the issue for me.
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
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.
Can confirm, I had the same problem on Arch, (mesa 25, kernel 6.13); removing the kernel parameter fixed it for me.
Thank you. I had the same problem and this seems to have solved the issue in my case.
1 Like
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.
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. 
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.
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
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
Thanks! This was my issue as well.
Not sure if it’s just me, I’m still seeing this on the latest Fedora 42
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.
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.
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?
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.
- Find the build on Koji (link).
- Download the files into a directory, either from the link above or using the
kojiCLI, eg:
Note: although the download includes a ton of othermkdir temp-mesa-fix cd temp-mesa-fix koji download-build --arch=x86_64 mesa-24.3.4-1.fc42 sudo dnf downgrade *.rpmmesa-related rpms,dnf downgradewill skip any that aren’t already installed on your system, so using*.dnfshould be safe. - After completing the download, pin
mesa-va-driversto the safe version to prevent accidentally updating it during normal system updates:
When you run updates,sudo dnf versionlock add mesa-va-driversmesa-*packages will still appear in the update list. However, when you actually run the update,versionlockwill prevent them from being updated, anddnfshould prevent dependency conflicts.
Later, when the bug is fixed, you can unlock the package with dnf versionlock delete mesa-va-drivers
I sadly have disabled my system by upgrading to 42…