iMac20,2 (Navi 10, 1002:7319 / 106b:021b) — SMU hw_init fails -62; ppfeaturemask workaround boots but leaves MCLK at 0 MHz

[Balba8]

Hardware

• Model: iMac20,2 (27", 2020)
• CPU: Intel Core i9-10910, 10 cores
• RAM: 32 GB
• GPU: Navi 10, PCI 1002:7319, subsystem 106b:021b, rev 40
• Display: internal 5K panel, 60 Hz

Software

• Fedora 44 KDE
• Kernel 7.1.9-200.t2.fc44.x86_64 (copr sharpenedblade/t2linux)
• Mesa 26.1.8, RADV
• Previously reproduced on 6.19.12-210.t2.fc44.x86_64

Problem 1 — amdgpu fails to probe without a ppfeaturemask workaround

With default parameters, amdgpu aborts during init:

amdgpu: Failed to enable requested dpm features!
amdgpu: Failed to setup smc hw!
amdgpu: hw_init of IP block failed -62
amdgpu: Fatal error during GPU init
amdgpu 0000:03:00.0: probe with driver amdgpu failed with error -62

Everything up to SMU succeeds: VBIOS is fetched from VFCT
(ATOM BIOS 113-D182A2XT-012), 16368M VRAM is registered, PSP and VCN
firmware load, all ten IP blocks are detected. Failure is isolated to
, roughly 3 seconds after init starts.

Note: there is NO "SMU: No response msg_reg" line in my log, unlike
issue #19 (iMac20,1 / Navi 14 / 1002:7340). The SMU appears to respond
but reject the feature-enable request. The existing patch gated on
Navi 14 device IDs does not apply to 1002:7319.

Only workaround found: nomodeset, which falls back to llvmpipe.

Problem 2 — amdgpu.ppfeaturemask=0xfff7bffd boots but kills MCLK

Booting with amdgpu.ppfeaturemask=0xfff7bffd avoids the -62 and gives a
working amdgpu/RADV stack. However memory clock never leaves 0 MHz:

rocm-smi under load: SCLK 1500Mhz, MCLK 0Mhz, GPU% 99, 54W

Dota 2 main menu: 22 FPS, GPU 99%.

Problem 3 — 0xfff7bfff works better, performance still far below expected

amdgpu.ppfeaturemask=0xfff7bfff boots reliably and restores MCLK:

idle: SCLK 800Mhz, MCLK 98Mhz, 41C, 11W
load: SCLK 1500Mhz, MCLK 750Mhz, 66C, 83W, GPU% 57

Dota 2 main menu with this mask: 41-42 FPS.

Forcing power_dpm_force_performance_level=high changed nothing (42 FPS).

Manually locking both clocks via pp_dpm_mclk/pp_dpm_sclk in manual mode
raised the menu to 79 FPS with stable frametimes (min 11.7 / max 13.9 ms).
In an actual match: 44 FPS, frametime min 9.2 / max 54.9 ms, with GPU
load at 35% and no CPU core above 15%.

Inconsistent DPM tables

pp_dpm_sclk reported three levels in one reading and two in another
during the same session:

reading A: 0: 300Mhz 1: 800Mhz * 2: 1500Mhz
reading B: 0: 300Mhz 1: 1500Mhz *

pp_dpm_mclk tops out at 750 MHz:

0: 98Mhz 1: 500Mhz 2: 625Mhz 3: 750Mhz

A retail 5700 XT reports a considerably finer table with a higher
memory ceiling. This suggests PMFW is not exposing the full state table
to the driver.

Ruled out by testing

• PCIe link: LnkCap and LnkSta both 8GT/s x16 — running at full speed
• Wayland vs X11: identical results in both sessions
• V-Sync off, FPS cap 240, fullscreen, in-game settings from Fastest to
  High, resolution 5120x2880 vs 2560x1440 — lowering resolution halved
  GPU load without changing framerate
• intel_lpmd: exits at boot on this CPU, not active

Willing to test

I can run patched kernels and provide logs. This machine appears to be
in the same failure class as #19 but with a different ASIC and device ID,
and I have not found any report covering 1002:7319 with Apple's
subsystem ID.

[Balba8]

Additional data — synthetic benchmarks run with clocks manually locked
(manual mode, pp_dpm_mclk=3, pp_dpm_sclk=highest):

glmark2 2023.01 (800x600 windowed): 19811
vkmark 2025.01 (default): 24414

Both are in the expected range for a healthy 5700 XT, which suggests the
raw rendering path and RADV are fine. The performance deficit appears
only under real workloads, consistent with PMFW mishandling DPM
transitions rather than a driver or hardware fault.