MacBookPro16,1 / Radeon Pro 5500M (Navi 14): SMU stops responding on first 3D load, GPU hangs hard — 27-boot log, working mitigation, possible link to #743

[3v3nFloW]

Hardware / software

• MacBookPro16,1 (16-inch 2019), i9, 32 GB, T2 firmware 23P6068 (macOS 26.6.2 on the other partition)
• dGPU: AMD Navi 14 1002:7340 rev 40, subsystem 106b:020f (Radeon Pro 5500M), VBIOS 113-D32206U1-019 (2019/10/10)
• iGPU: Intel UHD 630 (i915 loads, disabling eDP — no outputs, as documented)
• Linux Mint 22.3 XFCE, T2-Mint ISO linuxmint-22.3-xfce-7.0.9-t2-noble; reproduced identically on 7.0.9-1-t2-noble and 7.2.3-1-t2-noble (apt upgrade from the t2 repo)
• Firmware as loaded by amdgpu: smc 0x00352500 (53.37.0), sos 0x00160952, pfp 0x9b, me 0x64, mec 0x92, rlc 0x4c, sdma 0x29, vcn 0x07115002; "use vbios provided pptable"
• Kernel cmdline: pm_async=off intel_iommu=on iommu=pt quiet splash (ISO default), later amdgpu.ppfeaturemask=0xfff73fff (see below, no effect)
• X11 (lightdm + Xorg, amdgpu DDX with glamor), XFCE

Symptom

SMU initialises fine on every boot (SMU is initialized successfully! at ~7.8 s, smu driver if version = 0x38). The GPU then dies on the first real use of the gfx ring — in roughly 2 of 3 attempts — regardless of clock level or timing:

• Xorg start with glamor (login greeter): hang 10–90 s after X starts
• XFCE session start with autologin (compositor / Plank): same
• Brave WebGL app (Cornerstone3D DICOM viewer) after a surviving X start: hang within ~30 s, even with sclk forced to 300 MHz

Once the GPU has survived the first burst it runs for hours (observed 1 h+ of desktop use, browser, flatpak installs). After the hang the machine loses networking within 1–2 min and needs a hard power-off; a warm reboot after a hang fails to bring the SMU back (init errors), a cold boot is needed.

Signature in the kernel log — two orderings observed:

# boot 09:41 (7.2.3), X started at ~85 s with glamor, sclk 'auto'
[   96.482061] amdgpu 0000:03:00.0: SMU: No response msg_reg: 1c resp_reg: 0
[   98.545646] amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=679, emitted seq=679
[   98.545650] amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
[   99.667883] amdgpu 0000:03:00.0: SMU: No response msg_reg: 1c resp_reg: 0
[   99.667889] amdgpu 0000:03:00.0: Failed to set workload mask 0x00000001
[   99.667892] amdgpu 0000:03:00.0: (-62) failed to disable fullscreen 3D power profile mode
[  103.027512] amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
[  103.027515] amdgpu 0000:03:00.0: GPU reset begin!. Source:  1
[  107.027590] amdgpu 0000:03:00.0: failed to suspend display audio
# journal ends ~111 s

# boot 11:35 (7.2.3), X with glamor at ~10 s
[   16.302602] amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=667, emitted seq=669
[   16.302607] amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
[   16.491486] amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
[   16.491490] amdgpu 0000:03:00.0: GPU reset begin!. Source:  1
[   17.560081] amdgpu 0000:03:00.0: SMU: No response msg_reg: 40 resp_reg: 0
# journal ends 17.56 s

# boot 09:30 (7.0.9), after writing power_dpm_force_performance_level=high in a text console (no X)
[  241.783892] amdgpu 0000:03:00.0: SMU: No response msg_reg: 2a resp_reg: 0
[  241.783898] amdgpu 0000:03:00.0: Failed to disable gfxoff!
   (repeats every ~3 s)
[  251.366751] amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=677, emitted seq=679
[  251.366754] amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset

msg_reg seen: 0x1c, 0x2a, 0x40, 0x6 (init-time only in #743). One earlier hang also showed [CRTC:81:crtc-0] flip_done timed out before the SMU messages.

Hardware sanity check

macOS on the same machine: WebGL aquarium (webglsamples.org, 5000 fish) for 10+ minutes, fluid, no crash. So the GPU/VRM are fine; this is driver/firmware/power-sequencing on the T2 platform.

What was tried (27 boots on 2026-09-04)

Change	Result
power_dpm_force_performance_level=high (wiki tip)	kills the SMU immediately, even in a text console without X
low (300 MHz) before X start, or manual + pp_dpm_sclk "0 1"	X start survives sometimes; WebGL load still hangs at 300 MHz
amdgpu.dpm=0	driver aborts: Fatal error during GPU init, probe -95, no display at all
amdgpu.ppfeaturemask=0xfff73fff (default 0xfff7bfff minus GFXOFF bit 15)	GFXOFF shows disabled in pp_features; no change in behaviour
kernel 7.0.9 → 7.2.3	no change
X without acceleration (Option "Accel" "false", AutoAddGPU false)	always survives; switching to glamor later by restarting X works in every one of ~8 attempts if the GPU was idle before
loading appletbdrm at boot (modules-load.d)	X start hangs (third DRM device); loading it after X is up is fine
suspend/resume	display never comes back (known, #846-style), not investigated further

Timing of DPM writes matters: writing any forced level in the first ~10 s (sysinit-time service) coincided with hangs; writing low at 60 s in a console was harmless.

Mitigation that works reliably (10/10 cold and warm boots so far)

1. amdgpu-sclk-cap.service (sysinit, before display-manager): drop /etc/X11/xorg.conf.d/20-amdgpu-noaccel.conf with Option "Accel" "false" + AutoAddGPU false → greeter starts without glamor.
2. amdgpu-late.service (25 s after graphical.target): write low, remove the conf, systemctl restart lightdm (greeter comes back with glamor), 60 s later manual + pp_dpm_sclk "0 1" (300/500 MHz), then load appletbdrm + USB re-enumeration for tiny-dfr.
3. lightdm autologin off (a session starting before step 2 hits the GPU through the compositor and hangs it).
4. All 3D goes to the iGPU: DRI_PRIME=1 in /etc/environment and in the viewer's launcher. DRI_PRIME=1 glxinfo -B → Mesa Intel(R) UHD Graphics 630; Chromium reports ANGLE (Intel, Mesa Intel(R) UHD Graphics 630 …), WebGL2 + float textures. With that, the DICOM viewer (Cornerstone3D volumes) runs without any amdgpu error; amdgpu only scans out.

So the machine is usable, but the 5500M does nothing except display.

Possible link to #743 (iMac20,1, Radeon Pro 5300 = same Navi 14 die)

#743 shows the SMU mailbox wedging when FEATURE_DPM_UCLK is enabled during init, and that enabling it after init is accepted. Here the SMU survives init, but every hang happens exactly when the GPU is asked to leave idle — i.e. when UCLK/SCLK DPM switches levels under load — and forcing high (an immediate jump of both clocks) kills it instantly. pp_features on this machine: features high: 0x00000442 low: 0xa3cbafbb, DPM_UCLK (bit 3) enabled, MCLK levels 95/496/736/750 MHz, SCLK 300/500/1450 MHz.

I have not yet tested disabling DPM_UCLK at runtime (echo 0x00000442a3cbafb3 > pp_features) before the first 3D load, or pinning MCLK to one level via manual + pp_dpm_mclk. Happy to run either under instructions — each failed attempt costs a hard power-off, so I would like to hear whether that experiment is considered worthwhile for the 5500M before burning more boots.

Questions

1. Is this SMU wedge on first gfx load a known state for MacBookPro16,1 / 5500M on 7.x, and is there a recommended ppfeaturemask or pptable override for it?
2. Does the pm_async=off / vga_switcheroo deferral order on T2 (the 7.0.6 change discussed in CachyOS #846) play a role in the SMU losing its mailbox under DPM transitions?
3. Would a pp_features-based delayed-enable quirk like the one proposed in Workaround: iMac20,1 Radeon Pro 5300: DPM_UCLK causes intermittent SMU timeout at boot; delayed enable restores full performance #743 be acceptable upstream for Apple Navi 14 subsystems (106b:020f, 106b:0219)?

Full journals of the failing boots are available on request.

[3v3nFloW]

Update — confirmed: disabling DPM_UCLK at runtime makes the 5500M stable under full 3D load.

Test today (kernel 7.2.3-1-t2-noble, amdgpu.ppfeaturemask=0xfff73fff, X already running, power_dpm_force_performance_level=manual):

# pp_features before: high: 0x00000442 low: 0xa3c9afbb   (DPM_UCLK bit 3 enabled)
echo 0x00000442a3c9afb3 > /sys/bus/pci/devices/0000:03:00.0/pp_features
# after: DPM_UCLK disabled, DS_UCLK disabled, MEM_VDDCI/MVDD_SCALING still enabled, MCLK stays at 95 MHz

The SMU accepted the write without complaint. Then, rendering on the Radeon itself (no PRIME offload):

• glmark2 --size 1600x1000 --run-forever for 150 s: GFXCLK 1450 MHz, 99 % busy, ~25 W, 69 °C — no errors.
• Chromium/WebGL DICOM viewer (Cornerstone3D): 1414-image CT stack scrolled for 60 s, then GPU volume rendering of a 704-slice series (1450 MHz, 48 W peak, 74 °C) — no errors, GPU back to 6 W idle afterwards.
• dmesg | grep -iE "amdgpu.*(timeout|No response|reset|fail)" → 0 lines. Uptime now > 1 h with the GPU used continuously.

Before this change the same viewer killed the SMU within ~30 s even with GFXCLK forced to 300 MHz, so the trigger is the UCLK (memory clock) DPM transition, not the shader clock — consistent with #743 on the iMac20,1 (same Navi 14). Note the SMU only ever died when UCLK had to switch (first 3D load, high = both clocks jump); with UCLK pinned at its lowest state, GFXCLK is free to go 300↔1450 MHz.

Cost: memory clock is stuck at 95 MHz (the lowest DPM state). Volume rendering was still usable. Not yet tested: (a) amdgpu.ppfeaturemask with PP_MCLK_DPM_MASK (bit 1) cleared at boot — i.e. 0xfff73ffd — which would also remove the need for my "start X without acceleration first" workaround; (b) pinning UCLK to a higher fixed level via manual + pp_dpm_mclk with DPM_UCLK still enabled, to distinguish "transitions" from "high UCLK". I will report on both once I have a spare cold boot.

One correction to my first post: pp_dpm_sclk on this chip is fine-grained (line 0 = min, line 1 = current, line 2 = max), so writing 0 1 never capped GFXCLK at 500 MHz — it was running up to 1450 MHz all along.