Hardware
- Apple iMac20,1, 27-inch 2020
- AMD Radeon Pro 5300 / Navi14
- PCI device:
1002:7340
- Subsystem:
106b:0219
- Tested with linux-t2 7.1.x
Problem
With the existing Radeon Pro 5300 SMU allowed-feature quirk, the GPU initializes only intermittently.
The failure occurs during SMU feature enable and typically ends with:
SMU: No response msg_reg: 6 resp_reg: 0
Failed to enable requested dpm features!
Failed to setup smc hw!
hw_init of IP block <smu> failed -62
Fatal error during GPU init
probe with driver amdgpu failed with error -62
The important observation is that SMU mailbox query commands still work immediately before the failure.
I tested the LOW SMU feature mask one feature at a time and isolated the failure to:
FEATURE_DPM_UCLK_BIT = 3
mask bit = 0x00000008
The original LOW mask is:
Clearing only DPM_UCLK gives:
With:
LOW = 0xABC9AFB3
HIGH = 0xFFFFFD02
the Radeon Pro 5300 boots reliably and the SMU initializes successfully.
However, leaving DPM_UCLK disabled causes a severe performance regression.
Performance with DPM_UCLK disabled
During Counter-Strike:
MCLK: 0 MHz
SCLK: ~1640-1650 MHz
GPU Load: 98-99%
MEM Load: ~67-76%
pp_dpm_mclk reports:
Counter-Strike performance is substantially below the normal result.
Trying to select MCLK level 1 manually does not change the active MCLK state.
Runtime DPM_UCLK test
After the machine has completely booted and AMDGPU/SMU initialization has succeeded, I can enable only DPM_UCLK through pp_features.
Before:
features high: 0x00000402 low: 0xabc9afb3
03. DPM_UCLK : disabled
MCLK: 0 MHz
Runtime change:
echo 0x00000402abc9afbb > \
/sys/bus/pci/devices/0000:03:00.0/pp_featuresAfter:
features high: 0x00000402 low: 0xabc9afbb
03. DPM_UCLK : enabled
The SMU accepts the command successfully after initialization.
MCLK immediately becomes functional and dynamically scales between observed values including:
98 MHz
500 MHz
625 MHz
875 MHz
Under Counter-Strike load:
MCLK: 875 MHz
SCLK: up to ~1620 MHz
GPU Load: ~70-99%
MEM Load: ~20-37%
Counter-Strike performance returns to 300+ FPS, which is the same performance level I observed previously when booting successfully with DPM_UCLK enabled from the beginning.
Reproducible behavior
DPM_UCLK enabled during initial SMU setup
Result:
- full MCLK/UCLK performance when boot succeeds
- 300+ FPS
- intermittent SMU timeout / error
-62 during boot
DPM_UCLK disabled permanently
Result:
- reliable boot
- SMU initializes successfully
- MCLK/UCLK DPM unavailable
- major GPU performance regression
DPM_UCLK disabled for boot, enabled after initialization
Boot:
After successful AMDGPU initialization:
enable FEATURE_DPM_UCLK_BIT
Result:
- reliable boot
- runtime SMU feature enable succeeds
- normal MCLK scaling returns
- Counter-Strike returns to 300+ FPS
Current workaround
I currently boot with DPM_UCLK removed from the allowed LOW mask and use a oneshot systemd service after graphical initialization to enable bit 0x08 through pp_features.
After reboot:
service: active
features high: 0x00000402 low: 0xabc9afbb
03. DPM_UCLK : enabled
MCLK idle: 98 MHz
SMC Feature Mask: 0x00000402abc9afbb
This has so far provided both reliable initialization and normal GPU performance.
Possible kernel-side solution
Rather than permanently excluding FEATURE_DPM_UCLK, it may be possible to:
- exclude DPM_UCLK from the initial Radeon Pro 5300 allowed-feature mask;
- allow SMU/GPU initialization to complete;
- enable only
FEATURE_DPM_UCLK_BIT at a later safe point in AMDGPU initialization.
The key finding is that enabling DPM_UCLK during initial SMU setup can wedge the SMU mailbox, while enabling the exact same feature after initialization succeeds and restores normal UCLK/MCLK operation.
I can test kernel patches or provide additional boot logs, SMU feature-mask traces, and performance results if useful.
Hardware
1002:7340106b:0219Problem
With the existing Radeon Pro 5300 SMU allowed-feature quirk, the GPU initializes only intermittently.
The failure occurs during SMU feature enable and typically ends with:
The important observation is that SMU mailbox query commands still work immediately before the failure.
I tested the LOW SMU feature mask one feature at a time and isolated the failure to:
The original LOW mask is:
Clearing only DPM_UCLK gives:
With:
the Radeon Pro 5300 boots reliably and the SMU initializes successfully.
However, leaving DPM_UCLK disabled causes a severe performance regression.
Performance with DPM_UCLK disabled
During Counter-Strike:
pp_dpm_mclkreports:Counter-Strike performance is substantially below the normal result.
Trying to select MCLK level 1 manually does not change the active MCLK state.
Runtime DPM_UCLK test
After the machine has completely booted and AMDGPU/SMU initialization has succeeded, I can enable only DPM_UCLK through
pp_features.Before:
Runtime change:
After:
The SMU accepts the command successfully after initialization.
MCLK immediately becomes functional and dynamically scales between observed values including:
Under Counter-Strike load:
Counter-Strike performance returns to 300+ FPS, which is the same performance level I observed previously when booting successfully with DPM_UCLK enabled from the beginning.
Reproducible behavior
DPM_UCLK enabled during initial SMU setup
Result:
-62during bootDPM_UCLK disabled permanently
Result:
DPM_UCLK disabled for boot, enabled after initialization
Boot:
After successful AMDGPU initialization:
Result:
Current workaround
I currently boot with DPM_UCLK removed from the allowed LOW mask and use a oneshot systemd service after graphical initialization to enable bit
0x08throughpp_features.After reboot:
This has so far provided both reliable initialization and normal GPU performance.
Possible kernel-side solution
Rather than permanently excluding
FEATURE_DPM_UCLK, it may be possible to:FEATURE_DPM_UCLK_BITat a later safe point in AMDGPU initialization.The key finding is that enabling DPM_UCLK during initial SMU setup can wedge the SMU mailbox, while enabling the exact same feature after initialization succeeds and restores normal UCLK/MCLK operation.
I can test kernel patches or provide additional boot logs, SMU feature-mask traces, and performance results if useful.