FW13 AMD 7040: hard freeze / sudden power-off under WebRTC + UVC capture load — MES errors, persists on BIOS 3.18

[ericlegallais]

Device Information

System Model or SKU

Please select one of the following

• [X ] Framework Laptop 13 (AMD Ryzen™ 7040 Series)

BIOS VERSION

03.18

DIY Edition information

Memory: Manufacture and SKU
2x ADATA AD5S560016G-SFW (16 GB DDR5-5600 SODIMM each, 32 GB total — both purchased
from the Framework Marketplace). Identical part numbers, running at 5600 MT/s.
memtest86+ 7.00: 17 full passes over 13h23, 0 errors.

Storage: Manufacture and SKU
Western Digital WD_BLACK SN770 500GB (firmware 731100WD)

Port/Peripheral information

Port/Peripheral information

1. USB-C expansion card — DisplayLink dock (Dell D6000 at home / Targus DOCK430 at office; issue reproduces identically with both)
2. USB-A expansion card — Elgato Cam Link 4K (USB 0fd9:007b, UVC capture, used as meeting camera)
3. USB-C expansion card — empty
4. USB-A expansion card — Logitech Unifying Receiver (mouse)

• Peripheral most involved in the crashes: Elgato Cam Link 4K on port 2 (adjacent to the dock on port 1, same left side).
• Framework charger connected through the dock (port 1) during all crashes.
• Note: the dock and the Cam Link both sit on the left side (ports 1-2). Happy to test with the Cam Link moved to port 4 (right side) if useful for isolating a per-side PD/USB controller interaction.

Standalone Operation (Laptop Only)

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

• Yes
• [X ] No

Describe the bug

Under WebRTC video conferencing combined with UVC video capture (Google Meet or Slack huddle + Elgato Cam Link 4K), the system either:

• (a) hard-freezes (no SysRq, no logs written, hard power cycle required), or
• (b) freezes then powers off entirely (observed 2026-06-04, three times within 10 minutes — see "crash loop" in Additional context).

Forensic signature matches #206 exactly: journal cuts off mid-line, /sys/fs/pstore empty, /var/crash empty, no MCE/EDAC events, no amdgpu hangcheck/reset logged — the hang happens below the kernel logging layer.

Recurring kernel-log precursor (appears sporadically, minutes-to-hours before crashes, sometimes within 60 s of boot):

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

Chromium-side precursor seconds before several crashes:

ERROR:services/video_capture/video_capture_service_impl.cc:200] Bind context provider failed.

Notably, Chromium's own GPU watchdog has auto-blocklisted the iGPU on this machine (browser GPU process self-starts with --use-gl=disabled despite hardware acceleration enabled in settings) — an independent witness that the GPU stack is unstable.

Frequency before BIOS 3.18: 2-3 crashes/day. After 3.18 (AGESA PhoenixPI 1.2.0.0e): ~1 crash per 2 days — significant but incomplete improvement, consistent with an AGESA/PMFW-class bug. Never crashes when idle or under non-video load (incl. 13 h of memtest86+ at sustained 100 °C, 17 passes, 0 errors).

Related issues: #41 and #58 (same Phoenix 7040 SoC on FW16, same freeze-under-video-load family — this report adds the FW13 data point with a much more frequent, deterministic reproducer), #206 (identical forensic signature and MES involvement on different silicon).

Steps To Reproduce

1. Boot with DisplayLink dock attached (3-4 external displays via evdi).
2. Join a WebRTC video call (Google Meet in Chrome, or Slack huddle) using the Elgato Cam Link 4K as camera.
3. Wait 5-20 minutes.
4. System hard-freezes (sometimes followed by spontaneous power-off).

Crash-loop variant (2026-06-04): after a crash, the browser session-restores and auto-rejoins the call at login, re-triggering the crash within 1-7 minutes — three consecutive freeze-then-power-off cycles (13:34, 13:42, 13:45) until the call tab was closed. See attached crash-loop-logs.txt.

Expected behavior

No freeze or power-off under WebRTC + UVC capture load. Video conferencing with an external capture device is a standard daily workload for this machine.

Screenshots

memtest86+ 7.00 after 13h23: 17 passes, 0 errors (rules out the RAM, as requested by Framework support in my parallel support ticket):

Operating System (please complete the following information):

• OS/Distribution: Linux/Ubuntu
• Version: 24.04 LTS
• Linux Kernel Version: Linux eric-framework 6.17.0-29-generic #29~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon May 11 10:30:58 UTC 2 x86_64 x86_64 x86_64 GNU/Linux (HWE — issue also reproduced on 6.8.0-117-generic)
• Mesa: 25.2.8-0ubuntu0.24.04.1
• DisplayLink driver: 6.3.0-48 (Synaptics), evdi 1.14.16-186 DKMS

Additional context

Timeline / data points

Date	Event
2026-05-21/22	2-3 hard freezes/day during Meet (BIOS 3.16→3.17, kernel 6.8→6.17, evdi 1.14.16 — no change)
2026-05-22	Also reproduced in Slack huddle (Electron) — not Chrome-specific
2026-05-26	Freeze at 09:17 on second dock (Targus DOCK430, office) — not dock-model-specific
2026-05-28	BIOS 3.18 (AGESA PhoenixPI 1.2.0.0e) + UMA 4 GB ("Gaming") + Optimal Defaults + Secure Boot off
2026-05-30→06-01	Best uptime since onset (2+ days), then soft-hang during simultaneous Slack huddle + browser WebRTC
2026-06-04	Crash loop: 3 freeze-then-power-off events in 10 min (browser auto-rejoining call)
2026-06-05	memtest86+ 7.00: 17 passes, 13h23, 0 errors

Mitigations attempted (none eliminates the issue)

Mitigation	Effect
Chrome hardware acceleration off	Reduced frequency
Slack hardware acceleration off	Reduced frequency
amdgpu.sg_display=0	Reduced frequency
amdgpu.dcdebugmask=0x10	No clear change
i915.enable_psr=0	No change
BIOS 3.16 → 3.17 → 3.18	Largest improvement (2-3/day → ~1/2 days) — consistent with an AGESA/PMFW-class bug, partially addressed by PhoenixPI 1.2.0.0e
UMA frame buffer Auto (512 MB) → Gaming (4 GB)	Applied with 3.18, part of the same improvement
memtest86+ overnight	17 passes, 0 errors — RAM ruled out

Relationship to existing issues

• FW16 Freeze then Reboot (FTR) S5_RESET_STATUS = 0x08000800 <- Sync Flood. #41 (FW16 7040, Freeze-then-Reboot / Sync Flood) and FW16 Freeze then Hang (FTH) #58 (FW16 7040, Freeze-then-Hang): same Phoenix 7040 SoC, same freeze-under-video-load family. This report adds the FW13 7040 data point with a much more frequent, deterministic reproducer (WebRTC + UVC capture, ~daily) than FW16 Freeze then Reboot (FTR) S5_RESET_STATUS = 0x08000800 <- Sync Flood. #41's monthly occurrence.
• Framework Desktop (Ryzen AI MAX+ 395 / gfx1151): silent GPU hard hang under sustained compute on stock Ubuntu 26.04 LTS — suspected SMU/MES/PMFW firmware bug #206 (FW Desktop, silent GPU hang, suspected SMU/MES/PMFW): identical forensic signature (journal cut mid-line, empty pstore, hang below logging layer) and same MES involvement, on different silicon — suggesting a firmware-family issue rather than board-specific.

Questions

1. Is a PhoenixPI/AGESA update beyond 1.2.0.0e planned for the FW13 7040 BIOS that addresses MES/SMU hangs under concurrent VCN encode/decode + capture load?
2. Given the deterministic reproducer here (5-20 min, daily), I'm happy to run instrumented builds / collect SMU traces if useful.

Attachments

• previous-boot.log — full journal of a crashed boot
• crash-loop-logs.txt — final minutes of the three 2026-06-04 power-off boots
• lspci-lsusb.txt, system-info.txt, glxinfo.txt

crash-loop-logs.txt
glxinfo.txt
lspci-lsusb.txt
previous-boot.log
system-info.txt