## System details

AMD Ryzen 5 7600 (Raphael iGPU 1002:164e, unused) · AMD Radeon RX 6700 XT (Navi 22 / NAVY_FLOUNDER, 1002:73df), single monitor on the dGPU · MSI MAG B650 TOMAHAWK WIFI, BIOS 1.R3 (2026-09-07) · 32 GB RAM · Omarchy 4.0.4-1 · linux-omarchy 7.2.5-3 · linux-firmware-amdgpu 20260810-2 · Limine 12.8.0 + UKI, limine-mkinitcpio-hook 1.38.0 · LUKS-encrypted btrfs root · hibernation configured with `omarchy hibernation setup` (`/swap/swapfile`, `resume=/dev/mapper/omarchy_root resume_offset=…` on the cmdline, `HOOKS+=(resume)`)

## What's wrong?

**Hibernation never resumes on a desktop with an AMD RDNA2 discrete GPU.** `systemctl hibernate` (or Hibernate in the system menu) writes the image and powers off. On the next boot the image is found and read, but the restore is aborted and the machine falls into a cold boot with a broken display, so a hard reset is needed. Same result on two attempts, before and after a BIOS update.

This is the AMD counterpart of #10039. The mechanism is the same: the GPU driver is loaded from the initramfs (here by the `kms` hook), so when the boot kernel freezes devices right before jumping into the image, the driver's freeze callback runs against a fully initialized dGPU and fails, which discards the restore.

### Failure sequence (`journalctl -b <resume boot> -k`, identical on both attempts)

```
PM: hibernation: Read 3906752 kbytes in 1.72 seconds (2271.36 MB/s)
PM: Image successfully loaded
amdgpu 0000:03:00.0: MODE1 reset
amdgpu 0000:03:00.0: GPU mode1 reset
amdgpu 0000:03:00.0: GPU smu mode1 reset
amdgpu 0000:03:00.0: GPU mode1 reset failed
amdgpu 0000:03:00.0: PM: pci_pm_freeze(): amdgpu_pmops_freeze [amdgpu] returns -62
amdgpu 0000:03:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -62
amdgpu 0000:03:00.0: PM: failed to quiesce async: error -62
PM: hibernation: Failed to load image, recovering.
PM: hibernation: resume failed (-62)
amdgpu 0000:03:00.0: [drm] enabling link 0 failed: 15
```

What follows differs per attempt. First attempt: `BUG: Bad page state in process systemd-hiberna` during recovery, then a normal boot with no display output. Second attempt: the display pipeline hangs during the recovery boot (`[drm] *ERROR* flip_done timed out` on DP-1 repeatedly, then `WARNING: ... at dm_arm_vblank_event [amdgpu]` triggered by plymouthd) and the boot never reaches the session.

### Why the freeze fails

`amdgpu_pmops_freeze()` deliberately performs an ASIC reset for a dGPU in S4. On this card the SMU-driven mode1 reset times out (-62 / -ETIME). The kernel already contains the upstream S4 fix for this path on PSPv11 dGPUs ("drm/amdgpu: Fix wait after reset sequence in S4", merged in 7.0), so this is a driver bug that fix does not cover. The initramfs is what puts the driver in the position to fail: the `resume` hook runs in the same initramfs in which `kms` has already bound amdgpu to the card and taken the framebuffer console.

### Relationship to existing issues

- #10039: same failure shape on single-NVIDIA-GPU desktops (`nv_pmops_freeze` returns -EIO). The workaround proposed there, keep the driver out of the initramfs, applies here as well by dropping the `kms` hook.
- #9696 / `force-igpu`: not applicable, no supergfxctl, the dGPU drives the only display.
- #11437: hit on the same machine on the way here. After the swapfile had been removed and re-created, the stale `/etc/limine-entry-tool.d/resume.conf` made `omarchy hibernation setup` a silent no-op for the offset. Mentioned only because the fresh drop-in had to be forced manually before the resume attempts above could even find the image.

### Steps to reproduce

1. Desktop with an RDNA2 dGPU (RX 6700 XT here) and the stock Omarchy initramfs (`kms` hook present).
2. `omarchy hibernation setup`, reboot.
3. `systemctl hibernate`, power back on.
4. Image loads, freeze of `0000:03:00.0` fails, `PM: hibernation: resume failed (-62)`, cold boot with broken display.

### Expected

Either the image restores, or `omarchy hibernation setup` / `omarchy hibernation available` refuses on a configuration where the initramfs makes resume impossible, as suggested in #10039. A conditional `kms` drop for dGPU systems that opt into hibernation, along the lines of the NVIDIA-only `kms` removal already in `/etc/mkinitcpio.conf.d/omarchy_hooks.conf`, would be the matching fix.

### Workaround (confirmed)

A drop-in that filters `kms` out of `HOOKS`, sorted after `omarchy_hooks.conf` and `omarchy_resume.conf` so the `resume` hook is kept:

```bash
# /etc/mkinitcpio.conf.d/zz-no-kms.conf
_no_kms_hooks=()
for _no_kms_hook in "${HOOKS[@]}"; do
  [[ $_no_kms_hook == kms ]] || _no_kms_hooks+=("$_no_kms_hook")
done
HOOKS=("${_no_kms_hooks[@]}")
unset _no_kms_hooks _no_kms_hook
```

then `sudo limine-mkinitcpio`. The image loses all DRM modules (early CPIO 39 MiB -> 7 MiB), hook run order becomes `udev plymouth keymap consolefont encrypt resume`. Early boot runs on simpledrm; amdgpu loads from the root filesystem a few seconds after the switch. With this, hibernate and resume work on the first try:

```
PM: hibernation: hibernation entry
...
System returned from sleep operation 'hibernate'.
amdgpu 0000:12:00.0: SMU is resumed successfully!
amdgpu 0000:03:00.0: SMU is resumed successfully!
PM: hibernation: hibernation exit
```

Cost: LUKS prompt and Plymouth draw on the firmware framebuffer, and there is a mode switch when the compositor starts.