### System details

Omarchy 4.0.0-1, AMD Ryzen 9 5950X, 64 GiB RAM, NVIDIA GeForce RTX 4080 SUPER, Dell G2724D, 2560x1440 at 165.08 Hz over DisplayPort (`DP-3`) + VRR

### What's wrong?

### Summary

Two total desktop freezes on the same day, ~100 minutes apart. Both kill
display updates, all keyboard/mouse input, and audio playback simultaneously.
Neither recovers; both required a forced power-off. No panic message, no log
flush, nothing on screen. The second freeze happened with VRR disabled, after
the first had been attributed to an always-on VRR configuration change.

### Environment

| Component | Version |
|---|---|
| Distro | Arch-based (Omarchy 4.0), fully updated 2026-08-22 |
| Kernel | `linux 7.1.8.arch1-3` |
| Compositor | Hyprland `0.56.2-1`, aquamarine `0.14.0-2` |
| GPU driver | nvidia-open kernel modules + userspace `610.57.04-1`, egl-wayland `1.1.21-1` |
| GPU | RTX 4080 SUPER (AD103), display on DisplayPort, 2560x1440@165 |
| Motherboard / BIOS | Gigabyte X570 AORUS ELITE, F41a (latest) |

### Occurrence details

**Freeze 1** — seconds after launching a Firefox-based browser (a burst of new
Wayland surfaces and rendering work). An agent process driving the launch
stopped logging mid-command; the browser itself kept running ~10 s more,
completed shutdown handling, and wrote session state. Then total silence from
the whole machine.

**Freeze 2** — instant, on pressing a media-next key while audio was playing
through onboard analog output (so playback genuinely died, not a sink switch).
The very last line ever written to persistent journal by that boot:

```
systemd[1446]: Reached target Sound Card.
```

This was the only mid-session firing of `sound.target` in ~97 minutes of
uptime — a sound-device udev event at the exact halt instant. Pressing the same
key afterwards does not hang the machine, so the keybinding is not a
deterministic trigger.

### Evidence gathered

- On the boot immediately after Freeze 1, aquamarine logged twice during
  modesetting:
  ```
  ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
  ```
  The session then ran normally for hours — matching the "session survives
  with flip-loss warnings" case described in hyprwm/aquamarine#343.
- Persistent journald tails for both crashed boots are available.
- `/sys/fs/pstore/` empty after both hard power-offs (no kernel crash record
  survived).
- Both NVMe drives: SMART overall PASSED, 0–2% used, spare 100%, no critical
  warnings. Temperatures normal throughout.

### Ruled out

Across both boots' logs:

- OOM kills / swap exhaustion
- Kernel panic, hung-task, soft/hard lockup reports
- NVIDIA Xid errors, GSP heartbeat timeouts, GPU resets
- Machine check exceptions / hardware error events
- Thermal events
- Btrfs / NVMe I/O errors
- Coredumps at halt time (one unrelated post-reboot coredump was collateral
  damage from the unclean power-off)
- Orderly shutdown initiated by desktop or power-button daemon

### Interpretation (clearly a hypothesis)

Two freezes with entirely different triggers (browser-launch burst vs. single
media keypress), identical total-death outcome, and zero surviving kernel
diagnostics leave two suspect classes:

1. The shared graphics stack: kernel 7.1.x + nvidia-drm 610.57.04 +
   Hyprland/aquamarine page-flip handling (see cross-links)
2. An underlying hardware fault not yet exposed by any diagnostic

### Related upstream reports

- https://github.com/hyprwm/aquamarine/issues/343 — lost page-flip completion → EBUSY storm → userspace futex deadlock; silent mid-session stop, dead display/input, healthy kernel
- https://github.com/hyprwm/aquamarine/issues/353 — nearly identical stack (Hyprland 0.56.2 / aquamarine 0.14.0 / kernel 7.1.x); reporter stable on kernel 6.18 LTS
- NVIDIA forum threads reporting `Pageflip timed out!` Wayland freezes on 610.57.04

### Questions

1. Are total-freeze reports on Omarchy 4 + kernel 7.1.x + NVIDIA known?
2. Recommended mitigation order: `linux-lts` 6.18 kernel vs `AQ_NO_ATOMIC=1`
   vs pinning a different nvidia-open release?
3. Which logging should be pre-enabled so the next freeze yields usable proof
   (persistent compositor trace, sysrq configuration, etc.)?

Happy to attach sanitized journal excerpts and to test proposed kernels or
patches.