What about the multi-monitor video surface corruption? (appears as windows become polarized/black white) when moving between eDP and external monitors etc?
1 Like
Has someone tried to reproduce this issue using beta BIOS 3.05 ?
Yeah, you liked the post where I said I did. As said, I canāt reproduce with BIOS 3.05 (beta).
What about ā¦ when moving between eDP and external monitors etc?
Iām not entirely sure we are talking about the same thing, but while just using/unplugging an external monitor would, before, often trigger the graphical glitches of the sort described in this thread, this has still never happened for me on beta 3.05 (going on 3-4 days now).
1 Like
It was possibly a variation ; but unlike the case where the external became completely whited out and unusable until a reboot. It was observable when you dragged a window half between the eDP and external DP monitor.
If looked like colour surface related to my uneducated eyes. But otherwise didnāt result in an unusable external display.
I was only able to observe this running Plasma6 (Nobara and Fedora 40) and various 6.8 and 6.9 kernels.
1 Like
@Rijnder_Wever
Do you also not see anymore in dmesg logs :
[199821.668560] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[199821.668715] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
Could you also tell us your kernel version please for future reference ?
While this is on gnome/wayland, I did have issues with external displays prior to this bios. I attributed it to the scatter/gather issues weāve been seeing.
Using 6.8.4-300.fc40.x86_64 and 3.05b I can reliably use my external monitor which exposes a usb4 connection with displayport.
Is there anything that you do specifically that could provoke the behavior?
Coolermaster gp27u.
@Mario_Limonciello would you have any idea what fixed the issue in the latest bios release, was there an AMD AGESA bump ?
Correct.
2 Likes
updated to 3.05 today too, and removed also the amdgpu kernel parameter.
currently everything runs fine so far :3
4 Likes
Here to report the same as R1ck
4 Likes
@Mario_Limonciello Would the AGESA bump also fixx this problem on Lenovo Legion Slim 5 with 7840hs?
1 Like
Reporting that this issue seems to be fixed on my end as well:
Yesterday I removed the amdgpu.sg_display kernel parameter that Iāve had for a while. Been fine so far, yay!
Fedora 39 6.8.5-201.fc39.x86_64
BIOS 3.05
64GB (2x32GB) RAM
1 Like
I am reluctant to say yes without knowing the details of the AGESA binary versions on that system.
But conceptually if it was the same root cause as Framework it could help too.
You can compare SMU and IMU firmware versions before and after the upgrade for Framework and with this other system.
1 Like
Is there any news on AMD OpenSIL so that someday everyone can peer into AGESA source code or itās equivalent?
Everything for OpenSIL is posted to the OpenSIL GitHub:
Is this AGESAās open source code or itās something totally different from AGESA ? As AGESA has become proprietary for awhile now.
Theres a few talks and blogs out there. OpenSIL is planned to be the successor to AGESA.
3 Likes
I performed the BIOS update (3.03 ā 3.05) using LVFS through the KDE Discover software center today and I can report that the screen no longer flashes white like it did before occasionally in fullscreen YouTube videos (especially in power save mode on battery with lots of tabs) and it no longer engages in full panic flashing white screen requiring forced shutdown when I change between system and app scaling for X11 apps with an X11 app open. System now performs as expected, well done Framework team.
System:
Framework Laptop 13 7840U
32 GB RAM (16x2 Crucial 5600 MHz)
Fedora 39 KDE Plasma Spin (6.8.6-200.fc39.x86_64)
Mesa 23.3.6
No special kernel parameters or environment variables
5 Likes
I can confirm that the 3.0.5 firmware has resolved this issue for me. Since then I donāt see any glitches anymore even when not booting with amdgpu.sg_display=0.
I am on NixOS with kernel 6.8.6.
Tested this with an uptime of 3 days and several suspend-resume cycles.
1 Like
Updated BIOS, disabled the workarounds (both renamed to Game mode and amdgpu.sg_display=0) and currently running Linux laptop 6.8.4-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4 20:45:21 UTC 2024 x86_64 GNU/Linux
So far so good! 
I havenāt been able to trigger display corruption so far. amdgpu_top shows:
Iāll be in the office tomorrow where I have 2 external monitors (3 in total) via my docking station, Iāll report back then!
Well, Iāve been working on my 3 monitors today and it didnāt flinch, Iād say the new BIOS has fixed the issue!
Thanks for your hard work! 
1 Like