Skip to content

[FW16 AMD] amdgpu hangs with "MES failed to respond to msg=MISC (WAIT_REG_MEM)" recurring on Ryzen 9 7940HS / Radeon 780M #227

Description

@abagonhishead

Disclaimer: I had some help from Claude with some of this.

Device Information

System Model or SKU

  • 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)

CPU: Ryzen 9 7940HS · iGPU: Radeon 780M (Phoenix, gfx1103 / GC 11.0.1)

BIOS VERSION

04.04 (sudo dmidecode --string bios-version04.04; fwupd System Firmware 0.0.4.4, released 2026-03-23)

DIY Edition information

  • Memory: 2× A-DATA AD5S560032G-SFW — 32 GB DDR5 SODIMM each (64 GB total), DDR5-5600, running at 5600 MT/s (dual-channel, A+B)
  • Storage:
    • WD_BLACK SN7100 500GB (fw 7615M0WD)
    • WD_BLACK SN770M 1TB (fw 731100WD)

Port/Peripheral information

Expansion cards present:

  • DisplayPort
  • HDMI
  • 2x USB-C
  • 2X USB-A

Be aware that I haven't used the DP or HDMI cards since I bought the laptop -- they're there for convenience in case I ever need them. This reproduces while driving the internal display only.

Standalone Operation (Laptop Only)

  • Yes
  • No

Describe the bug

During normal use, the kernel logs recurring amdgpu MES (MicroEngine Scheduler) timeouts:

amdgpu 0000:c2:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
amdgpu 0000:c2:00.0: amdgpu: failed to reg_write_reg_wait

The errors are intermittent but frequent — 9 occurrences in one ~1.5-hour session, and 38 over a ~21-hour boot. They occur on the stock/default kernel command line (no amdgpu overrides; default GPU power management, ppfeaturemask=0xfff7bfff) and appear tied to GPU power-state transitions.

Severity / history (important):

  • On the previous firmware (BIOS 03.05) I experienced freezes and hard hangs.
  • Since updating to BIOS 04.04 (today, 28th June 2026), I have not had a freeze/hang so far — but the underlying MES errors are still present and unchanged. Given the errors persist, it seems likely only a matter of time before the hangs return.
  • So 04.04 may have reduced the severity but has not resolved the root cause.

No GPU reset (amdgpu: GPU reset) is logged when the MES timeout occurs; the system otherwise remains responsive at the moment of the error.

Steps To Reproduce

Not deterministic — the errors track GPU GFXOFF (idle⇄active) power-state transitions, so they accrue during ordinary use rather than from one specific action:

  1. Boot with the default kernel command line (no custom amdgpu parameters).
  2. Use the system normally (desktop / web browsing / light GPU activity with idle periods).
  3. MES failed to respond to msg=MISC (WAIT_REG_MEM) accrues in dmesg / journalctl -k (ambient rate here ≈ 1 per 10 min).

Accelerant (probabilistic, not deterministic): repeatedly cycling a GPU app on/off — forcing GFXOFF exit then re-entry — measurably raises the rate. In a controlled test, cycling glxgears (~2 s on / ~2 s off) produced 2 errors in ~3 min vs ~1 per 10 min ambient (~6× elevation), consistent across two separate runs:

# terminal 1 — watch:
journalctl -k -f | grep --line-buffered "MES failed"
# terminal 2 — cycle GPU load:
while true; do vblank_mode=0 glxgears & sleep 2; kill %1; sleep 2; done

Expected behavior

GPU power-state transitions should complete without MES scheduler timeouts. No MES failed to respond / failed to reg_write_reg_wait entries in the kernel log, and no associated freezes/hangs.

Screenshots

I will include the following below:

  • journalctl -k grepped for amdgpu
  • A full export of chrom://gpu

Operating System (please complete the following information):

  • OS/Distribution: Linux Mint (across both Cinnamon and GNOME)
  • Version: 22.3 "Zena"
  • Linux Kernel Version: 6.17.0-35-generic (Linux russbook4 6.17.0-35-generic ... x86_64 GNU/Linux)

Additional context

Firmware / driver versions:

Component Version
BIOS 04.04 (fwupd System Firmware 0.0.4.4, 2026-03-23)
AGESA / PhoenixPI PhoenixPI-FP8-FP7 1.2.0.0e
SMU / PMFW 76.101.0
iGPU Radeon 780M — Phoenix, gfx1103 / GC 11.0.1 (mes_v11_0, mes_kiq_3.1.0)
Mesa 25.2.8
linux-firmware 20240318.git3b128b60-0ubuntu2.27 (MES blob gc_11_0_1_mes*)

Did the firmware update help? Updating from the factory BIOS 03.05 → 04.04 did not resolve the MES errors (it may have reduced hang frequency — see history above — but the errors persist).

Userspace GPU state: Currently no userspace impact — chrome://gpu reports full hardware acceleration (Canvas, Compositing, Rasterization, WebGL, WebGPU, Video Decode all hardware-accelerated) with GPU process crash count 0 and no GPU hang/crash in "Problems Detected".

Related issues (likely the same Phoenix MES/SMU/PMFW firmware family — filing separately to give complete FW16/04.04 detail without derailing another thread; happy for triage to merge):

  • #221closest match. Framework Laptop 13 (AMD 7040, same Phoenix gfx1103 iGPU), identical MES signature (MES failed to respond to msg=MISC (WAIT_REG_MEM) / failed to reg_write_reg_wait) and the same AGESA PhoenixPI 1.2.0.0e I'm on here (FW16 04.04). Same "BIOS reduced frequency but didn't resolve" pattern. Differs in chassis (FW13) and has a specific trigger (WebRTC + UVC capture); it also reports Chromium auto-blocklisting the iGPU — which I do not see here (see Userspace GPU state above), suggesting I'm at a lower current severity on the newer BIOS. Their hard-freeze/power-off symptom does match the freezes/hangs I had on my previous firmware (03.05).
  • #41 & #58same product (FW16 7040), freeze-under-video-playback family, but a different error class (S5 Sync-Flood reboot / freeze-then-hang, neither logs a MES timeout). Same chassis as this report; different signature.
  • #206 — same broad MES/SMU/PMFW family and MES involvement, but different silicon (Framework Desktop, Strix Halo gfx1151). Notably links a forum report of an SMU deadlock in dcn35_smu_enable_pme_wa triggered by GPU-accelerated browser workloads → ring timeouts → MES failures — possibly the same underlying SMU/PMFW fault reached via a different driver path.

Mitigations attempted: BIOS 03.05 → 04.04 (reduced/eliminated hangs so far, but MES errors persist unchanged). Planned to test next: amdgpu.sg_display=0 (reported to reduce crash frequency in #221). amdgpu.dpm=0 as a last resort.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions