Fix iMac20,2 AMDGPU startup race

[aurelienbottazini]

[!NOTE] 90% AI
It was particularly painful to do all the manual reboots and testing :)

Summary

• Detect only the affected iMac20,2 with AMD/Apple PCI IDs
  1002:7319 / 106b:021b.
• Add amdgpu.ppfeaturemask=0xfff7bffd to the generated Limine command line so
  the memory-clock feature group is not enabled during the fragile SMU probe.
• Restore DPM_UCLK, MEM_VDDCI_SCALING, and MEM_MVDD_SCALING after the display
  manager starts, with guards for the boot parameter and exact hardware IDs.
• Cover fresh installs and existing systems with an idempotent migration.

Problem

On this 2020 27-inch iMac, AMDGPU initialization fails intermittently before
the display manager starts. A failed boot consistently contains:

apple_gmux: Found gmux version 5.0.0 [T2]
amdgpu 0000:03:00.0: SMU: No response msg_reg: 6 resp_reg: 0
amdgpu 0000:03:00.0: Failed to enable requested dpm features!
amdgpu 0000:03:00.0: Failed to setup smc hw!
amdgpu 0000:03:00.0: hw_init of IP block <smu> failed -62
amdgpu 0000:03:00.0: Fatal error during GPU init

This happens during the kernel probe, so delaying SDDM did not address it.
Loading AMDGPU early from the initramfs also did not address it.

Why this workaround

The default AMDGPU feature mask on the tested kernel is 0xfff7bfff.
Clearing PP_MCLK_DPM_MASK (0x2) gives 0xfff7bffd. On Navi10 that keeps
the following features out of the initial SMU allowed-feature set:

• DPM_UCLK, bit 3
• MEM_VDDCI_SCALING, bit 8
• MEM_MVDD_SCALING, bit 9

With that boot mask, the GPU initializes reliably. Once userspace reaches the
display manager, writing the original three bits back through pp_features
restores memory-clock scaling without a kernel error. The helper preserves all
other feature bits and verifies that the three requested bits were accepted.

The workaround fails closed unless both the exact kernel parameter and all four
PCI IDs match. It discovers the PCI address through sysfs rather than assuming
03:00.0.

Hardware and software tested

Model:              Apple iMac20,2 (Mac-AF89B6D9451A490B)
CPU:                Intel Core i7-10700K
GPU:                Radeon Pro 5700 XT / Navi10
PCI IDs:            1002:7319, subsystem 106b:021b
Omarchy:            4.0.2-1
Kernel:             7.1.8-arch1-Watanare-T2-3-t2

Validation

• A captured unmasked boot reproduced all six SMU/GPU initialization errors
  above and failed the AMDGPU probe with -62.

• amdgpu.dpm=0 was tested as a negative control. It failed differently with
  firmware loading/probe error -95 and is not used here.

• An SDDM readiness gate was tested as a negative control. It could not help
  because the GPU failure precedes SDDM.

• Four consecutive boots with amdgpu.ppfeaturemask=0xfff7bffd completed with
  no Failed to setup smc hw, SMU block-init, or fatal GPU-init messages.

• The automatic late restore completed with:

  AMDGPU runtime memory-clock features enabled: 0x00000662a3d9afbb
  

• DPM_UCLK, MEM_VDDCI_SCALING, and MEM_MVDD_SCALING all read back enabled, and
  MCLK returned from the boot-time 0 MHz state to 98 MHz idle.

• brcmfmac remained loaded during the successful boots, so Wi-Fi driver
  removal was not responsible for the result.

Related T2 reports:

• iMac20,2 (T2, Navi10): intermittent amdgpu initialization failures t2linux/wiki#646
• Workaround: iMac20,1 Radeon Pro 5300: DPM_UCLK causes intermittent SMU timeout at boot; delayed enable restores full performance t2linux/wiki#743

The second report independently isolates early DPM_UCLK enablement on the
iMac20,1 Radeon Pro 5300 and demonstrates a kernel-level late-enable approach.
The Omarchy change is intentionally a hardware-scoped userspace workaround
until the T2 kernel carries an equivalent fix for 1002:7319 / 106b:021b.

Tests

bash test/shell.d/imac20-amdgpu-uclk-test.sh
test/cli
git diff --check

The new focused test covers hardware matching, nearby-device rejection, feature
restoration, boot-mask enforcement, fresh setup, migration, and migration
idempotence. It passes both directly and as part of ./test/all.

./test/all was also run. It completed with five unrelated failures that
reproduce unchanged on the clean upstream checkout:

• bar-icon-geometry-test.sh (live Quickshell geometry)
• launch-about-test.sh (live animation check)
• config-test.sh (missing sibling omarchy-pkgs checkout)
• snapper-test.sh (missing sibling omarchy-pkgs checkout)
• unowned-system-paths-test.sh (missing sibling omarchy-pkgs checkout)

[vivekchauhan]

I have faced exactly same issue with display freezing intermittently post login on Omarchy, a bug report was filed here
https://gitlab.freedesktop.org/drm/amd/-/work_items/5674

Please see if that provides any additional context.

[edschofield]

I have a related kernel fix under review at t2linux/linux-t2-patches#60, also submitted to AMD yesterday as an RFC. It follows the delayed-UCLK work by Atharva Tiwari and Guna R. Bharati discussed in t2linux/wiki#743.

The machine I tested on is an iMac20,1 with Navi14 1002:7340 / 106b:0218, revision 0x41. The patch defers only UCLK, leaves both memory-voltage features enabled, and updates the driver's clock state after enabling it. In my local testing, the AMD staging kernel with my patch passed ten warm boots with rendering and video checks, whereas an unpatched AMD staging kernel reproduced the message-6/-62 failure. The linked RFC records the separate T2 warm/cold coverage and its limits.

The current patch does not match this PR's Navi10 7319/021b board, so I cannot claim that it fixes your machine. It may be useful as the basis for a kernel-side adaptation with testing on that hardware.

There is also a parser detail in the current helper worth checking. On my machine, pp_features begins with one line:

features high: 0x00000462 low: 0xa3dbbfbb

The T2 7.1.8 source uses that format too. Testing the helper's current awk expression against this output reads high but returns an empty value for low; the test fixture instead puts them on separate lines. Could you check
that against the helper used for your successful trials? After fixing the parser, the complete pp_dpm_mclk output would also help verify that the driver's clock table agrees with the restored firmware features.