On Sat, 24 Oct 2026 18:21:09 +0200, Andre Eikmeyer wrote: > The Radeon Pro 5300M and 5500M of the MacBookPro16,1 (Navi 14 boards > 1002:7340/106b:0210 and 1002:7340/106b:020f) stop answering SMU messages > as soon as UCLK switches into its third level.
This is the hang reported in drm/amd issue 6005, which has the umc_info analysis and test results from both boards: https://gitlab.freedesktop.org/drm/amd/-/work_items/6005 Could v2 carry a Closes: tag for it? I tested the patch on a MacBookPro16,1 with the Pro 5300M (1002:7340 rev 0x43, 106b:0210, VBIOS 113-D32207P1-019), on linux-t2 7.2.11 (Arch v7.2.11-arch1 plus the t2linux patches) with this patch on top. The userspace pp_table upload from the issue was disabled for these boots, so the corrected levels came from the patch alone. All at DPM auto unless noted: - both "UCLK level ..." lines at boot and again after every resume, pp_dpm_mclk 95/496/598/736 - forced pp_dpm_mclk switches through every level transition, idle and under memtest_vulkan load (57 switches, every 3 s): all landed - UCLK pinned at level 2 (598 MHz): llama.cpp benchmark and 180 s of memtest_vulkan, no errors - 60 min soak of llama.cpp runs with idle gaps, and 30 min of normal desktop use with the soak running - 8 deep suspend/resume cycles (rtcwake, lid, systemctl suspend) I ran these with the internal panel on the iGPU and again with the Radeon driving it (apple-gmux force_igd=n). No "SMU: No response", GPU reset, ring timeout or DC errors in any of them. With the stock driver, level 2 hung within seconds. For the runs with the Radeon on the panel I also had amdgpu.dcdebugmask=0x1. That is for a separate DC issue (the MPC pipe split on the 3072x1920 eDP plane makes DRAM clock change unsupported, so UCLK stays at the top level). It is not related to this patch and I will report it separately. Tested-by: James Skillen <[email protected]> # MacBookPro16,1, Pro 5300M (106b:0210) The testing above and this reply were prepared with help from claude-opus-5-5; I have checked the results and the text. Thanks, James
