Public bug reported: This report is written by/from Claude Fable 5's research after I had the problem(had incident) and had discussed it with the Claude: https://claude.ai/code/session_01WHEuwv9jLP5D7Ry6EzmF7f
TITLE: linux-firmware 2.29 SRU downgraded DCN 3.1.4 (Phoenix) DMCUB firmware (0x08005300 -> 0x08004800), causing fatal display engine crashes and shutdown hangs SUGGESTED TAGS: regression-update noble amdgpu (This was debugged live on the affected machine in a Claude Code session; transcript: https://claude.ai/code/session_01WHEuwv9jLP5D7Ry6EzmF7f The appendix at the bottom lists the exact commands and observations.) ===================================================================== SUMMARY ===================================================================== The noble SRU linux-firmware 20240318.git3b128b60-0ubuntu2.29 replaced the DMCUB firmware blob for AMD Phoenix APUs (DCN 3.1.4) with an OLDER build than what -0ubuntu2.27 shipped: the kernel-reported DMUB version went from 0x08005300 (all boots on 2.27) down to 0x08004800 (all boots on 2.29). On the downgraded blob, the DMCUB microcontroller fatally crashes during eDP display power-state transitions (both display-off and display-wake directions), permanently wedging the entire display pipeline until reboot. Two fatal crashes occurred within ~21 hours of cumulative uptime after the update, versus zero DMCUB errors across ~47 hours / 6 boots on the previous blob with the *identical kernel*. Hardware: Lenovo IdeaPad Slim 3 15AHP10, Ryzen 7 8840HS (Phoenix, Radeon 780M iGPU, DCN 3.1.4), eDP internal panel (no PSR support). OS: Ubuntu 24.04 (noble), kernel linux-image-7.0.0-28-generic (7.0.0-28.28~24.04.1, HWE), installed 2026-07-17 — unchanged across the entire before/after window. This report separates (A) findings mechanically verified from logs and registers, and (B) downstream symptoms established only by clinical observation/correlation, so that triage can weigh each accordingly. ===================================================================== A. MECHANICALLY VERIFIED FINDINGS (hard log/register evidence) ===================================================================== A1. Firmware version regression across package versions ------------------------------------------------------- Kernel log "Loading DMUB firmware via PSP" per boot: boots 2026-08-10 .. 08-12 (pkg 2.27): version=0x08005300 -> no DMCUB errors, 6 boots, ~47 h boots 2026-08-13 .. 08-15 (pkg 2.29): version=0x08004800 -> 2 fatal crashes in 3 boots, ~21 h dpkg.log: linux-firmware upgraded 2.27 -> 2.29 on 2026-08-12 21:14:52. The version number DECREASED (0x53 -> 0x48 in the third field), i.e. the SRU shipped an older DMCUB build for this ASIC. Changelog attribution: the 2.28 entry contains "amdgpu: update DMCUB to v0.0.232.0 for DCN314 and DCN351" plus ~25 "DMCUB updates for various ASICs" commits in 2.28/2.29; the 2.27 entry contains no amdgpu changes at all. Hence the DCN314 blob lineage is: 2.26 == 2.27 (known good), changed in 2.28/2.29 (regressed). A2. Fatal crash #1 — 2026-08-14 21:19:08 KST (display-off transition) --------------------------------------------------------------------- The GPU's own display microcontroller (UTCL2 client DCEDMC) took a page fault on a GART address with no valid mapping: amdgpu 0000:05:00.0: [mmhub] page fault (src_id:0 ring:153 vmid:0 pasid:0) in page starting at address 0x0000000006026000 from client 18 MMVM_L2_PROTECTION_FAULT_STATUS:0x00000932 Faulty UTCL2 client ID: DCEDMC (0x4) WALKER_ERROR: 0x1 PERMISSION_FAULTS: 0x3 MAPPING_ERROR: 0x1 RW: 0x0 Context (verified from journal): 5 minutes of total system idle before the fault; GNOME idle-delay is 180 s; mutter's KMS thread was rtkit-promoted in the same second as the fault; the immediately following errors are dcn20_wait_for_blank_complete "failed to blank crtc" — i.e. the crash happened inside the display-off (CRTC blank) sequence. Afterwards, every DMCUB command times out permanently ("DMCUB error - collecting diagnostic data" storm, "[CRTC:368:crtc-1] hw_done or flip_done timed out"). A3. Fatal crash #2 — 2026-08-15 09:57:09 KST (display-wake transition) ---------------------------------------------------------------------- Same signature class, opposite direction, on a boot whose init was clean: DMCUB errors begin at 09:57:09 (again same-second with mutter KMS thread rtkit promotion), followed by "enabling link 0 failed: 15", repeated "failed to blank crtc", and "REG_WAIT timeout 1us * 10 tries - optc3_lock". No MMU page fault this time — the firmware died without an invalid access, so the failure mode is not exclusively the A2 fault path. A4. DMUB trace buffer fingerprint — identical terminal sequence --------------------------------------------------------------- Post-mortem dumps of /sys/kernel/debug/dri/1/amdgpu_dm_dmub_tracebuffer after BOTH crashes end with a byte-identical event sequence, parameters included: trace_code=33 (param1=33554688) -> 286 -> 294 -> 295 -> 296 (param0=2) -> 297 (param0=27000) -> 298 (param0=1) -> 299 -> 300 (param0=350) -> [no further entries] The firmware died executing the same routine both times. (Interpretive note, not verified: param0=27000 at code 297 matches a 2.7 Gbps eDP link rate expressed in 100 kbps units, consistent with an eDP link-management routine.) A5. Eliminated hypotheses (verified negative evidence) ------------------------------------------------------ - PSR/Replay: panel reports "Sink support: no" for both (debugfs psr_capability / replay_capability) — PSR code paths cannot be involved. - Memory hardware: zero MCE/EDAC events in all relevant boots. - Kernel regression: kernel binary unchanged since 2026-07-17; ran ~4 weeks incident-free on the 2.27 blob, crashes began only after the blob swap. - Suspend/resume: no suspend occurred in either crashed boot. ===================================================================== B. CLINICALLY OBSERVED DOWNSTREAM SYMPTOMS (correlation/inference) ===================================================================== These are consistently reproduced observations whose *mechanism* we infer but did not trace at register level: B1. After the DMCUB wedge, all modeset paths block: a VT switch (chvt) hangs in uninterruptible D-state indefinitely. B2. Shutting down while the display engine is dead hangs the machine indefinitely AFTER "Journal stopped" (deliberately reproduced: >8 min, fans on, NumLock LED still toggling — kernel interrupts alive, the shutdown thread blocked; inferred to be amdgpu device-shutdown waiting on dead DMCUB). A forced power-off (long power-button press) is the only exit. Note this makes the failure worse than a display outage: an unattended machine cannot even power itself off cleanly. B3. The first power-on after such a forced cut takes a firmware recovery path: either a slow POST (~20 s to GRUB instead of ~2 s) or a power-on that self-aborts once before a subsequent attempt succeeds. Easily misdiagnosed as "laptop won't boot"; EC register diffs and the SMBIOS event log show no fault records, supporting the interpretation that this is normal unclean-shutdown recovery behavior triggered by B2. ===================================================================== REPRODUCIBILITY / IMPACT ===================================================================== - Trigger: routine eDP display power transitions (idle screen-off and screen-wake). No exotic workload required; the machine crashed once per day of ordinary desktop use. - Impact: total loss of display until reboot; shutdown hang requiring forced power-off (B2); very confusing recovery behavior (B3). - Race-conditioned: one 10.5 h boot on the bad blob survived; two others died. Probabilistic per transition, certain over time. ===================================================================== WORKAROUND ===================================================================== Downgrading to 20240318.git3b128b60-0ubuntu2.26 (still published in noble-security) restores the pre-regression DCN314 blob lineage (2.26 == 2.27 for this file per changelog) and is being used with apt-mark hold as a local mitigation. ===================================================================== EVIDENCE / ATTACHMENTS ===================================================================== Attached forensic bundle (collected live during both incidents): - version-timeline.txt — per-boot DMUB versions + dpkg history - kernel-boot0-full.log — full kernel log of crash #1 boot - crash-window-all-units.log — all-unit journal around crash #1 - kernel-boot-instance2.log — full kernel log of crash #2 boot - crash-window-instance2.log — all-unit journal around crash #2 - dmub-tracebuffer-postmortem.txt / dmub-tracebuffer-instance2.txt — post-mortem DMUB trace dumps (see A4) - linux-firmware-2.29-changelog.txt — SRU changelog excerpt - incident-report.md — full investigation narrative Happy to provide any additional data (apport-collect, further debugfs dumps, testing candidate blobs) on request. ===================================================================== APPENDIX: INVESTIGATION LOG (commands run -> what was observed) ===================================================================== All commands were run over mosh on the affected machine while its display was dead, during each incident. Chronological. --- Incident 1 (2026-08-14, ~21:22 KST onward) --- journalctl -b -p err -> continuous "dc_dmub_srv_log_diagnostic_data: DMCUB error" storm from 21:19, interleaved "failed to blank crtc", "flip_done timed out". journalctl -b | grep -B5 -m5 "DMCUB error" -> first occurrence of the storm at 21:19:08, immediately preceded by the [mmhub] page fault block (client DCEDMC, addr 0x6026000, WALKER_ERROR, MAPPING_ERROR — full text in section A2). Also found ONE isolated DMCUB error at 13:17:20, seconds after amdgpu init of that boot. journalctl --since 21:14 --until 21:19:09 (all units) -> no user/session activity for 5+ min before the fault; the only event in the fault second: rtkit-daemon promoting a thread of gnome-shell (mutter KMS thread) — i.e. a display state transition was starting. cat /sys/class/drm/card1-eDP-1/{enabled,dpms,status} -> enabled / On / connected, while no frame could actually be presented. sudo chvt 3; sudo chvt 2 -> chvt 3 succeeded; chvt 2 never returned. ps showed chvt in D state: every modeset path blocks in-kernel indefinitely. sudo cat /sys/kernel/debug/dri/1/amdgpu_firmware_info -> DMCUB feature version 0, firmware version 0x08004800. sudo cat /sys/kernel/debug/dri/1/eDP-1/psr_capability (and replay_*) -> "Sink support: no" for PSR; Replay config unsupported. PSR eliminated. sudo cat /sys/kernel/debug/dri/1/amdgpu_dm_dmub_tracebuffer (post-mortem) -> 2751 entries; terminal sequence as in section A4 (attached). journalctl --list-boots + per-boot greps -> boots -1..-4: zero "DMCUB error" lines. Only the crashed boot (and its init at 13:17:20) shows any. for each boot: journalctl -b N -k | grep "Loading DMUB firmware" -> boots on pkg 2.27: version=0x08005300 (all clean); boots on pkg 2.29: version=0x08004800 (crashes). Table in A1. grep linux-firmware /var/log/dpkg.log -> "2026-08-12 21:14:52 upgrade linux-firmware 2.27 -> 2.29". grep linux-image-7.0.0-28 /var/log/dpkg.log* -> kernel installed 2026-07-17 (constant across the whole window). zcat /usr/share/doc/linux-firmware/changelog.Debian.gz (entries 2.27-2.29) -> 2.29/2.28: dozens of "amdgpu: DMCUB updates ..." commits, including "update DMCUB to v0.0.232.0 for DCN314 and DCN351" (2.28); 2.27 entry: no amdgpu changes at all. journalctl -b -k | grep -iE "mce|edac|corrected" -> nothing. Memory-hardware hypothesis eliminated. --- Incident 2 (2026-08-15, ~10:00 KST onward) --- journalctl -b -k | grep -c "DMCUB error" -> 93 (this boot). journalctl -b -k | grep -m3 "DMCUB error|Loading DMUB" -> same blob 0x08004800 loaded 08:31:48; FIRST error 09:57:09 — this boot's init was clean (weakens any "bad init marker" pattern). journalctl --since 09:54 --until 09:57:30 -> again rtkit/mutter-KMS promotion in the same second as first error; then "enabling link 0 failed: 15", repeated "failed to blank crtc", "REG_WAIT timeout 1us * 10 tries - optc3_lock". No page fault this time: display-WAKE direction, different proximate failure, same component. sudo cat .../amdgpu_dm_dmub_tracebuffer (post-mortem #2) -> terminal sequence byte-identical to incident 1, parameters included (section A4; both dumps attached). --- Downstream verification (same day) --- systemctl poweroff --force from the dead-display state -> journal's last line "Journal stopped" 10:26:00; machine then observed hung >8 min (fans on, NumLock LED toggling on keypress = interrupts alive, shutdown thread blocked). Long-press power cut required. -> next power-on: ~20 s of black screen before GRUB (normally ~2 s). sudo dmidecode -t 15 (before/after) -> Change Token 0x00000008 unchanged: firmware event log recorded nothing for any of this. ec_sys register dump diff (dead-display vs healthy boot) -> 2 bytes of telemetry-level jitter only; EC state not implicated. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-firmware 20240318.git3b128b60-0ubuntu2.29 ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: chleosl 3274 F.... wireplumber /dev/snd/controlC0: chleosl 3274 F.... wireplumber /dev/snd/seq: chleosl 3269 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Aug 15 10:43:36 2026 Dependencies: firmware-sof-signed 2023.12.1-1ubuntu1.11 InstallationDate: Installed on 2025-04-19 (483 days ago) InstallationMedia: Ubuntu 24.04.2 LTS "Noble Numbat" - Release amd64 (20250215) MachineType: LENOVO 83KA ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=5ea7efbf-07d4-4e5a-a129-ddacb7536f84 ro quiet splash amdgpu.accel=1 i8042.reset=1 vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-7.0.0-28-generic N/A linux-backports-modules-7.0.0-28-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux-firmware UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/18/2025 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: QACN22WW dmi.board.asset.tag: No Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: IdeaPad Slim 3 15AHP10 dmi.ec.firmware.release: 1.20 dmi.modalias: dmi:bvnLENOVO:bvrQACN22WW:bd03/18/2025:br1.22:efr1.20:svnLENOVO:pn83KA:pvrIdeaPadSlim315AHP10:rvnLENOVO:rnLNVNB161216:rvrNODPK:cvnLENOVO:ct10:cvrIdeaPadSlim315AHP10:skuLENOVO_MT_83KA_BU_idea_FM_IdeaPadSlim315AHP10:pfaIdeaPadSlim315AHP10: dmi.product.family: IdeaPad Slim 3 15AHP10 dmi.product.name: 83KA dmi.product.sku: LENOVO_MT_83KA_BU_idea_FM_IdeaPad Slim 3 15AHP10 dmi.product.version: IdeaPad Slim 3 15AHP10 dmi.sys.vendor: LENOVO ** Affects: linux-firmware (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 amdgpu apport-bug noble regression-update wayland-session -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163554 Title: DCN314/Phoenix DMCUB 0x08004800 page-faults at GART 0x6026000 during eDP power transition, wedging display (2.29 regression) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2163554/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
