Skip to content

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

Description

@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):

Image

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

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

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