### System details

Dell XPS 13 DX13260 (Intel Wildcat Lake, `xe` driver), Omarchy 4.0.4-1

### What's wrong?

## Summary

Since `linux-omarchy 7.2.5-3` was installed, closing the lid hangs the machine
hard. The session locks correctly and `systemd-sleep` begins the sleep
operation, but the kernel never completes the suspend path and never returns.
The panel stays lit (it is powered off later in the sequence, which is never
reached) and all input is dead, because userspace is already frozen at that
point. The only way out is holding the power button.

Booting the stock Arch `linux` kernel on the same machine, with a byte-identical
kernel command line, suspends and resumes normally. Every suspend failure is on
`linux-omarchy`; every suspend success is on stock `linux`.

## Expected vs actual

- **Expected:** lid close locks the session and the machine suspends, resuming on lid open.
- **Actual:** lid close locks the session, then the machine wedges with the backlight on and input dead. Hard power-off required.

## Impact

Unrecoverable lockup and forced power cycle on every lid close. Four unclean
shutdowns in under 24 hours on this machine.

## Evidence

Suspend outcomes across every boot in the journal, by kernel:

```
BOOT   KERNEL               TRIGGERED  ENTERED    RESUMED
-12    7.2.3-arch1-3        3          3          3
-11    7.2.3-arch1-3        1          1          1
-10    7.2.3-arch1-3        3          3          3
-9     7.2.3-arch1-3        1          1          1
-7     7.2.3-arch1-3        2          2          2
-6     7.2.3-arch1-3        2          2          2
-5     7.2.5-3-omarchy      1          0          0
-4     7.2.5-3-omarchy      1          0          0
-3     7.2.5-3-omarchy      1          1          0
-2     7.2.5-3-omarchy      1          0          0
 0     7.2.3-arch1-3        1          1          1

TOTAL  7.2.3-arch1-3        13         13         13
TOTAL  7.2.5-3-omarchy       4          1          0
```

(TRIGGERED = `logind: Suspending...`, ENTERED = `PM: suspend entry`, RESUMED = `PM: suspend exit`.)

The regression lines up exactly with the package install. The last successful
resume was at `21:12:17`; `linux-omarchy` was installed 30 seconds later:

```
2026-09-15T21:12:17  kernel: PM: suspend exit          ← last good resume, on 7.2.3
2026-09-15T21:12:47  [ALPM] installed linux-omarchy (7.2.5-3)
2026-09-15T21:14:44  (first hang, on 7.2.5-3-omarchy)
```

Tail of the journal at a representative hang (boot -2). Note the lock completes
and reports `secure=true`, so this is not a lock-screen issue:

```
17:36:40  omarchy-shell[4440]: qml: omarchy lock 2026-09-16T21:36:40.165Z secure=true
17:36:40  systemd[1]: Reached target Sleep.
17:36:40  systemd[1]: [email protected]: Unit now frozen-by-parent.
17:36:40  systemd[1]: user.slice: Unit now frozen.
17:36:40  systemd-sleep[7728]: Successfully froze unit 'user.slice'.
17:36:40  systemd-sleep[7728]: Performing sleep operation 'suspend'...
          ← end of journal; machine hard-powered-off
```

One of the four hangs (boot -3) got `PM: suspend entry (s2idle)` onto disk
before wedging, confirming the kernel does reach the suspend path:

```
06:34:15  systemd-sleep[5310]: Performing sleep operation 'suspend'...
06:34:15  kernel: PM: suspend entry (s2idle)
          ← end of journal
```

**Caveat on the logs:** because each hang ends in a hard power-off, the journal
loses whatever was not yet flushed, so the last recorded line varies between the
four hangs. The recorded stopping point is a lower bound on how far suspend got,
not the precise hang location.

## Steps to reproduce

1. Dell XPS 13 DX13260 (Intel Wildcat Lake, `xe` driver), Omarchy 4.0.4-1.
2. Boot `linux-omarchy 7.2.5-3`.
3. Close the lid.
4. Machine locks, then wedges with the backlight on and input dead. Hard power-off required.
5. Boot stock `linux 7.2.3-arch1-3` and repeat step 3: suspends and resumes normally.

## System details

```
Omarchy:   4.0.4-1
Machine:   Dell Inc. XPS 13 DX13260
BIOS:      1.6.0 (2026-07-16)
CPU:       Intel(R) Core(TM) 5 320
GPU:       Intel Wildcat Lake [Intel Graphics] (rev 01), driver: xe
Hyprland:  0.56.2 (v0.56.2, efb5099)
mem_sleep: [s2idle] deep
Kernels:   linux-omarchy 7.2.5-3 (fails) / linux 7.2.3.arch1-3 (works)
```

## Ruled out

- **Not the lock screen.** The lock completes and reports `secure=true` before suspend begins.
- **Not the kernel command line.** Both kernels boot with byte-identical cmdlines (verified via `/proc/cmdline` and the `Command line:` journal entry):
  ```
  cryptdevice=PARTUUID=6e7eb81e-…:root root=/dev/mapper/root zswap.enabled=0
  rootflags=subvol=@ rw rootfstype=btrfs rtc_cmos.use_acpi_alarm=1
  resume=/dev/mapper/root resume_offset=1917212 initramfs_async=0 quiet splash
  loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0
  ```
- **Not a userspace regression.** `omarchy`/`omarchy-settings` went 4.0.3-1 → 4.0.4-1 in the same pacman transaction, but stock `linux` suspends fine on 4.0.4-1 (boot 0 above).
- **Not a stuck inhibitor.** Only the usual delay inhibitors are present (NetworkManager, UPower, 1Password, `omarchy-sleep-lock`), and `logind` proceeds past them into `systemd-sleep` in every failing case.

## Root cause

Unknown. Bisected to the kernel package, but no backtrace is available: the
journal cannot flush once the machine wedges. The `xe` driver on Wildcat Lake is
the obvious suspect given the lit panel, but that is a hypothesis, not a finding.

## Workaround

Prefer the stock kernel via a `limine-entry-tool` drop-in that survives Omarchy
updates (`/etc/limine-entry-tool.d/zz-prefer-stock-kernel.conf`):

```
BOOT_ORDER="linux, linux-t2, linux-omarchy, linux-omarchy-*, *, *fallback, Snapshots"
```