Skip to main content

Framework Desktop GPU Hangs and Crashes (Strix Halo)

Summary​

The Framework Desktop (AMD Ryzen AI Max+ 395, gfx1151) experiences multiple distinct GPU stability issues ranging from recoverable ring timeouts to silent hard hangs requiring a power cycle. The issues manifest under both mundane workloads (Slack, Electron apps) and sustained GPU compute (LLM inference). AMD has confirmed a race condition in SMU command serialization and is developing a fix123.

Symptoms​

Three distinct variants have been identified:

Variant 1 — GFX ring timeout under mundane GL load​

  • amdgpu ring gfx_0.0.0 timeout in kernel log1
  • MES reset fails, MODE2 reset succeeds
  • Screen goes black, then recovers after 5-30 seconds
  • Triggered by trivial applications like Slack or other Electron apps1
  • Can happen every couple hours under normal use

Variant 2 — Silent GPU hard hang under sustained compute​

  • iGPU wedges under sustained GPU compute (typically LLM inference)2
  • Journal cuts off mid-line — no graceful shutdown
  • Requires hard power cycle (power button hold)
  • No pstore/BERT record left after reboot
  • amdgpu hangcheck never fires2
  • Root cause: SMU/MES/PMFW firmware bug (PMFW 100.6.0)2

Variant 3 — GPU driver fails to load entirely​

  • System fails to boot into any OS with functioning GPU driver3
  • Windows only boots in Safe Mode or with GPU drivers removed
  • Linux distributions only boot with nomodeset kernel parameter
  • May indicate hardware failure — requires RMA3

Affected Models​

  • Framework Desktop (AMD Ryzen AI Max+ 395) — all configurations with 64 GB or 128 GB memory123
  • The issue is specific to the gfx1151 (RDNA 3.5) graphics architecture

Root Cause​

AMD developer Mario Limonciello (@superm1) confirmed a race condition in SMU (System Management Unit) command serialization as the root cause of Variant 2. AMD has a reliable reproduction and a fix is in progress, tracked at drm/amd work_items/51712.

For Variant 1, the GFX ring timeout is triggered by mundane OpenGL workloads. The MES (Micro-Engine Scheduler) fails to reset the ring, but MODE2 reset (full GPU reset) succeeds. This suggests a firmware-level scheduling issue1.

For Variant 3, at least one reporter discovered their crash was actually caused by a faulty PSU — swapping the PSU resolved it completely. This suggests some reports may be hardware-related rather than firmware2.

Diagnosis​

  1. Check kernel logs for GFX ring timeouts:

    sudo dmesg | grep -E '(ring gfx|MES|MODE2|amdgpu.*timeout)'

  2. Enable persistent journaling for post-crash analysis:

    sudo mkdir -p /var/log/journal
    sudo systemd-tmpfiles --create --prefix /var/log/journal
    sudo systemctl restart systemd-journald

    After a hard hang, check: journalctl -b -1 | tail -50

  3. Check if pstore captured anything:

    ls /sys/fs/pstore/
    dmesg | grep -i bert

  4. Monitor PMFW version:

    cat /sys/class/drm/card*/device/amdgpu/pm_info 2>/dev/null | head -5

Workarounds & Fixes​

SolutionEffectivenessNotes
amdgpu.gpu_recovery=1 kernel parameter1Effective for Variant 1Enables MODE2 reset recovery instead of hard freeze. The GPU still crashes, but the system recovers automatically
amdgpu.cwsr_enable=0 kernel parameterFor compute workloadsDisables CWSR (Compute Wave Store/Restore). May reduce compute performance
Check PSU health2Fixes hardware-caused hangsIf amdgpu.gpu_recovery=1 does not help, the PSU may be faulty. Consider the Overtek 500 W replacement PSU
Vulkan backend for LLM inference4More stable than ROCmUse Vulkan/RADV backend in llama.cpp instead of ROCm/HIP for better stability
Downgrade to kernel 6.18.54TemporarySome regressions in newer kernels may worsen stability
Not effective

The following kernel parameters are no-ops on Ubuntu stock kernels and will not help:

  • amdgpu.mes=0 — already the default behavior on this kernel build
  • pci=ecrc=on — CONFIG_PCIE_ECRC is not built into Ubuntu stock kernel

Resolution​

AMD has confirmed the root cause (SMU race condition) and is actively developing a fix, tracked at drm/amd work_items/51712. No ETA has been given for the fix.

For Variant 3 (driver fails to load), this may indicate hardware failure and requires contacting Framework support for RMA3.

Footnotes​

  1. Strix Halo GFX1151 GFX ring timeout under mundane GL load — Framework Community (May 1, 2026) ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. GitHub Issue #206 — Desktop silent GPU hard hang (SMU/MES/PMFW bug) — GitHub (Apr 23, 2026) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Framework Desktop Failing to Load GPU Drivers — Framework Community (Jul 19, 2026) ↩ ↩2 ↩3 ↩4 ↩5

  4. Framework Desktop general stability — Framework Community ↩ ↩2