## What happened
After a long suspend, the NVIDIA driver's GPU memory/address-space state doesn't
get cleanly saved and restored, leading to BAR1 virtual-address-space exhaustion
shortly after resume. In my case this manifested as Chromium renderer crashes
(SIGILL via Chromium's deliberate ud2/CHECK-trap in the Media thread), but the
underlying driver problem is independent of Chromium.

Timeline (all times MST, kernel log):
- 22:08:19 — system suspends (deep/S3)
- 22:08:20 — system resumes, ~3 days after suspending
- 22:11:23–22:11:31 — repeated kernel errors:
    NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping.
    NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY]
      ... @ mapping_reuse.c:273 / kern_bus_gm107.c:3152
    [drm:__nv_drm_gem_nvkms_map [nvidia_drm]] *ERROR* Failed to map NvKmsKapiMemory
- 22:11:26 — kernel: traps: Media[4097] trap invalid opcode ip:... in chromium
  (Chromium's renderer Media thread executes `ud2` — its IMMEDIATE_CRASH()/CHECK
  trap — because a GPU memory mapping it needed failed)

GPU recovers on its own within minutes; no further NVRM errors since. Only the
one renderer/tab died, browser survived, no data lost. A prior crash with the
identical fault address/thread occurred 2026-09-02 on a fresh boot under genuine
VRAM pressure (4 GB Quadro T1000), so the driver is already tight on headroom
even without the suspend factor compounding it.

## Root cause
`nvidia-suspend.service`, `nvidia-resume.service`, and `nvidia-hibernate.service`
(shipped by `nvidia-utils`) are all `disabled` on a stock Omarchy nvidia install.
`install/hardware/nvidia.sh` installs the driver, sets `nvidia_drm modeset=1`,
and configures mkinitcpio early-loading — but never enables these three units.
They exist specifically to save/restore GPU memory state across sleep, and the
Arch wiki recommends enabling them for any NVIDIA laptop
(https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend).

## Expected
`install/hardware/nvidia.sh` should `systemctl enable` the three services (and/or
set `NVreg_PreserveVideoMemoryAllocations=1` for the DKMS driver) so GPU memory
state survives suspend on NVIDIA hardware, the way the Arch wiki recommends.

## Steps to reproduce
1. Install Omarchy on NVIDIA laptop hardware (here: ThinkPad P17 Gen 1, Quadro
   T1000 Mobile, nvidia-open-dkms 610.57.04).
2. Suspend for an extended period (reproduced after ~3 days; shorter suspends
   may also trigger it, untested).
3. Resume, then use GPU-accelerated content in Chromium (hardware video decode
   in my case).
4. Watch `dmesg`/journal for `NVRM: ... can't alloc VA space` / `NV_ERR_NO_MEMORY`
   around the same time as an app crash or GPU glitch.

## System
- Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, Hyprland 0.56.2
- ThinkPad P17 Gen 1, Intel i7-10850H
- NVIDIA Quadro T1000 Mobile (TU117GLM), driver 610.57.04, nvidia-open-dkms
- `nvidia-suspend.service` / `nvidia-resume.service` / `nvidia-hibernate.service`: all disabled, loaded

Full `omarchy-debug --no-sudo --print` output available on request.

I checked for existing reports (title search across omacom/omarchy's issues,
open+closed) and didn't find a match. Closest neighbors are all a different
mechanism or trigger: #9505 (Chromium main-process SIGTRAP on VM close, same
"hard-CHECKs on GPU trouble" family but different process/signal), #8394
(Chromium SIGTRAP in an OAuth popup), #9765 (different laptop hard-freezing
after deep suspend — a system freeze, not an app crash), #8470/#10158
(1Password SIGILL, but a genuine missing-instruction illegal opcode, not a
deliberate CHECK-trap).

Filed by Claude Sonnet 5 via Claude Code.