Framework Desktop GPU hang / hard freeze when playing video in Chromium (BIOS 03.03, Arch + kernel 6.19)

Framework Desktop Linux
1

Which Linux distro are you using?
Arch Linux (running Omarchy 3.6.0)

Which release version?
Rolling. last full update today, 2026-05-02

Which kernel are you using?
6.19.13-arch1-1

Which BIOS version are you using?
03.03 (2025-09-16, INSYDE Corp.) I checked LVFS via fwupd and this is the latest available there

Which Framework Desktop model are you using?
Ryzen AI MAX+ 395 with the Radeon 8060S iGPU (PCI 1002:1586)

Hi

Looking for some company in a sanity check here. My Framework Desktop hard-locks when I play video in Chromium for long enough full screen freeze, only the power button gets me out. It’s happened several of times today :frowning:

The pattern is consistent: open Chromium (Wayland, ANGLE on Vulkan), play a YouTube video, do my thing for a bit, and somewhere after several minutes the whole machine just stops. Sometimes the next boot also has trouble bringing the display up cleanly the first time and I need a second reboot. Feels very firmware-y.

I dug through journalctl -b -1 and these are the trace. The hang opens with the SMU getting stuck:

amdgpu: SMU: I'm not done with your previous command:
        SMN_C2PMSG_66:0x00000032 SMN_C2PMSG_82:0x00000000
amdgpu: Failed to power gate VPE!
amdgpu: Failed to disable gfxoff!   (this then repeats every ~5s)
amdgpu: ring sdma0 timeout, signaled seq=57225, emitted seq=57227
amdgpu: Starting sdma0 ring reset
amdgpu: ring sdma0 test failed (-110)
amdgpu: Ring sdma0 reset failed
amdgpu: GPU reset begin!. Source: 1

Then during the recovery attempt, the display clock manager keeps timing out talking to the SMU, twice, both via dcn35_smu_send_msg_with_param:

WARNING ... dcn35_smu_send_msg_with_param
  → dcn35_smu_set_zstate_support  → dcn35_update_clocks
  → dcn35_smu_set_dispclk          → dcn35_update_clocks
  inside dm_suspend → amdgpu_device_gpu_recover
Both end with "SMU response after wait: 0"

And recovery never finishes, so I power-cycle. On the messed-up boot afterwards I see this on the way back up:

[drm:dcn20_wait_for_blank_complete] *ERROR* DC: failed to blank crtc!
REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc
REG_WAIT timeout 1us * 100000 tries - optc35_disable_crtc

I am not expert and not sure what’s happening here.

Workaround after Googling that’s working so far: I disabled VAAPI hardware video decode in Chromium, so video gets decoded on the CPU. In ~/.config/chromium-flags.conf:

--disable-features=VaapiVideoDecoder,VaapiVideoEncoder
--disable-accelerated-video-decode
--disable-accelerated-video-encode

GPU rendering / WebGL is still on (--use-angle=vulkan). Video plays totally fine and I haven’t crashed since.

A few questions:

  1. Other Framework Desktop folks on Linux is this familiar?
  2. Framework staff: is there a tracking thread or known-issue list for this specific dcn35_smu_send_msg_with_param hang during video playback? I couldn’t find one but I might be searching wrong.

Thanks!

1 Like
2
1 Like
3

It also has been happening on my system. Specifically using the hardware video acceleration on Chromium. It happens usually after the video stream ends. Firefox seems fine with video acceleration enabled.