screen output freezing irregularly

[Artim96]

Device Information

System Model or SKU

Please select one of the following

• Framework Laptop 12 (13th Gen Intel® Core™)
• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (AMD Ryzen™ AI 300 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)
• Framework Laptop 16 (AMD Ryzen™ AI 300 Series)
• Framework Desktop (AMD Ryzen™ AI 300 PRO Series)

BIOS VERSION

Any version of the past year, including the latest 4.03

DIY Edition information

If you are experiencing an issue on a DIY system, Please also fill out the memory and storage devices you are using.

Memory: Crucial DDR5 RAM 32GB (2x16 GB) - CT2K16G56C46S5
Storage: WD_BLACK SN850X - WDS400T2X0E

Port/Peripheral information

Doesn't apply

Standalone Operation (Laptop Only)

Are you running your mainboard as a standalone device. Is standalone mode enabled in the BIOS?

• Yes
• No

Describe the bug

In irregular intervals, screen output (at least to the internal screen and to external screens via DP) just completely freezes. At the same time, these entries appear in the systemd journal:

Jan 17 08:27:44 framework16 kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Jan 17 08:27:44 framework16 kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Jan 17 08:27:44 framework16 kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Jan 17 08:27:55 framework16 kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* [CRTC:363:crtc-0] flip_done timed out

This issue has been present now for at least half a year, and it's yet to be figured out if this is a Linux, a firmware/BIOS or a hardware issue. Though the fact that I haven't heard of any other AMD 7040 series laptops having that issue suggests a Linux issue to be rather unlikely. I'm experiencing this on Debian, but reports from other distros suggest it's at least not limited to Debian: https://community.frame.work/t/fw16-screen-freezeing-on-linux/73958

The frequency of this issue seems to be influenced by the version of the Linux kernel; on some, this happens more frequently than on others. Also in that thread, people claimed that only a mainboard replacement was able to fix this, which indicates it may be a hardware issue, making it questionable if it can be fixed with software. The only way to recover from this is to turn off the device for at least 20-30 minutes, or it will happen again after a reboot within a minute. This makes it sound like a thermal issue, but I have never been able to detect any abnormally high temperatures at the sensors, and as it can also happen within minutes of turning the laptop on after it has been turned off for several hours, also makes this unlikely. Furthermore, I did try to replace the liquid metal pad with a PTM pad to maybe fix it (if it was a thermal issue), but no changes.

There are two very interesting findings, though: on one hand, this issue can't be triggered at will; either it happens or it doesn't. But it can be prevented by playing a video in the foreground, even if you didn't turn off the machine for at least 20-30 minutes. Not sure how, but it seems to make it impossible that the issue happens while a video is playing. My guess is that either a different mode the GPU is set to for hardware acceleration is preventing it or maybe the fact that the screen is being updated at least 25 times per second. On the other hand, I tried reproducing it in a Fedora 43 live ISO USB. While one would expect that when the issue happened in Debian and the USB was immediately booted, it should reappear, but it doesn't. Also, it seems to be happening way less frequently on F43, though that may be related to the Linux kernel version it ships with. It does happen on F43, though I have not yet been able to execute the log-gathering script I got from the support ticket when it does; either I hadn't set up SSH yet or the internet connection dropped at the same time, making access impossible.

For issue #161 I am in the process of getting a mainboard replacement already to provide you with known affected hardware, so once I have a functional replacement I will report on here as well if it still happens.

Steps To Reproduce

Wait. There's literally no way to trigger this at will.

Expected behavior

The output to never freeze.

Screenshots

NA

Operating System (please complete the following information):

• OS/Distribution: Debian Testing, Fedora 43
• Version: see above
• Linux Kernel Version: currently Linux framework16 6.19-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.19~rc4-1~exp1 (2026-01-11) x86_64 GNU/Linux, but has happened for months now.

Additional context

The support ticket runs under the subject "FW16 motherboard RMA", there you can get all information, logs etc I've already submitted there.

[csnover]

There are several distinct bugs related to screen freezes, the main tracking issue for the one related to your kernel logs is probably this amdgpu driver issue (there are quite a few other open ones). Deep in that ticket is a link to some plan to create a recovery path but I don’t know where that work is being tracked.

[Artim96]

Interesting. It seems AMD has really dropped the ball over the last months. This is already the second quite severe bug, after the months long screen glitch out bugs. But it still stands that a couple of users did state their issue was gone after a mainboard replacement, so there does seem to be some component on a lower level.