Skip to content

install/hardware/nvidia.sh never enables nvidia-suspend/resume/hibernate services, leaving stale GPU memory after suspend (causes Chromium renderer SIGILL crashes) #10433

Open
Open
install/hardware/nvidia.sh never enables nvidia-suspend/resume/hibernate services, leaving stale GPU memory after suspend (causes Chromium renderer SIGILL crashes)#10433
Labels
bugSomething isn't working

Description

@mudiam
mudiam
opened on Sep 6, 2026

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.

Activity

  1. burninc0de commented on Sep 6, 2026

    @burninc0de
    burninc0de
    on Sep 6, 2026

    Also hit this on desktop — not just laptops.

    Hardware: Omarchy 4.0.2, kernel 7.1.9-arch1-2, Hyprland 0.56.2, GTX 1660 TU116 (nvidia-open-dkms 610.57.04), Dell P2419H on DP-1, deep sleep

    Symptom: ~11s black after resume before lockscreen appeared. Quickshell.screens empty until DP link re-trained, omarchy lock stuck on hasRealScreen() -> lock-pending: no-real-screen + idleBlankTimer 8000ms blanked at 8s stealing focus. Symptom different from Chromium SIGILL but same stale VRAM root cause.

    Before: nvidia-suspend/resume/hibernate.service all disabled, only options nvidia_drm modeset=1, no PreserveVideoMemoryAllocations. PM: suspend exit to idle-monitor: active = 11s, systemd-suspend 5.08s wall, no nvidia-resume.service log.

    After fix (repro):

    sudo systemctl enable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service nvidia-suspend-then-hibernate.service
echo 'options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp' | sudo tee /etc/modprobe.d/nvidia-power.conf
sudo limine-mkinitcpio
# + Service.qml idleBlankTimer 8000->30000 (keeps unlock lit after wake)

    Reboot -> PreserveVideoMemoryAllocations: 1, next resume: PM: suspend exit -> nvidia-resume.service same second, lock secure=true pre-suspend preserved, display instant (no DP scan), systemd-suspend 3.58s. Confirms fix.

    Happy to have this baked into install/hardware/nvidia.sh per Arch wiki.

  2. kvnloo commented on Sep 12, 2026

    @kvnloo
    kvnloo
    on Sep 12, 2026
    Contributor

    NVIDIA / DPMS / scale cluster — Omarchy install + session env only. Not a hyprland-wm bug.

    Already in flight — do not compete / do not retarget:

    If the compositor is at fault, that is a Hyprland issue — I will not open a hyprland-wm PR. No competing Omarchy PR from me unless maintainers want the GSP-arm enable as a follow-up to #8127.

  3. adamlrutledge commented on Sep 20, 2026

    @adamlrutledge
    adamlrutledge
    on Sep 20, 2026

    Reproduced the same root cause on different hardware — ASUS ROG Zephyrus G14 (GA403WW), NVIDIA RTX 5080 Laptop GPU, driver 610.57.04. Wanted to flag two things for anyone hitting this from a search:

    1. The suggested fix direction above (PreserveVideoMemoryAllocations=1) made things worse in my case, not better. On this laptop, that combined with the missing services caused a freeze on wake from sleep, and a full lockup on the Omarchy boot logo on the next restart attempt (needed a hard power-off to recover). This matches other reports of that same combination causing unrecoverable black screens on NVIDIA laptops. The fix that actually worked here was enabling the three services and explicitly setting NVreg_PreserveVideoMemoryAllocations=0.
    2. A second contributing factor: gpu-screen-recorder, if installed, ships its own /etc/modprobe.d config that silently force-sets PreserveVideoMemoryAllocations=1 — which can re-trigger this even after applying the fix above. Worth checking whether that's specific to how Omarchy packages it.

    Verified fixed on this machine with an actual sleep/wake test after reboot — no freeze, no crash-pattern in logs, driver reports PreserveVideoMemoryAllocations: 0 live and post-resume.

    Filed by Claude Sonnet 5 via Claude Code.

  4. omarchybot
    added
    bugSomething isn't working
    on Sep 27, 2026

  5. omarchybot commented on Oct 11, 2026

    @omarchybot
    omarchybot
    on Oct 11, 2026
    Collaborator

    Thanks for the detailed report, @mudiam, and to @burninc0de and @adamlrutledge for testing it on other machines. I checked what a stock install sets up today. The claim that Omarchy never enables these units is correct. But on the open-module driver, leaving them disabled is what the driver package itself chose, so the missing units are not yet shown to be the cause.

    What was checked, on a disposable Omarchy worker against quattro at bef30c1c5, with nvidia-utils 610.57.04-1 and gpu-screen-recorder 6.1.0-1:

    • install/hardware/nvidia.sh writes only nvidia_drm modeset=1 and the early-load MODULES line. Nothing in the repository enables, disables or masks nvidia-suspend, nvidia-resume, nvidia-hibernate or nvidia-suspend-then-hibernate, and on a fresh install all four are disabled.
    • That is deliberate upstream. The nvidia-utils install script disables all four units when upgrading from anything older than 595.58.03, with the note that on 595+ open modules "video memory preservation is handled by kernel suspend notifiers, making the nvidia suspend/hibernate services unnecessary". The package ships /usr/lib/modprobe.d/nvidia-sleep.conf with NVreg_UseKernelSuspendNotifiers=1, and the 610.57.04 README (chapter 20) says the same: with the open modules and that option on, preservation "is handled automatically", and the systemd units are for the proprietary driver.
    • gpu-screen-recorder, which Omarchy installs by default, adds /usr/lib/modprobe.d/gsr-nvidia.conf with NVreg_PreserveVideoMemoryAllocations=1. So a stock open-module install runs with notifiers on, Preserve=1 and the units off.
    • Omarchy's initramfs includes modconf, so these options also apply when the module is early-loaded. That rules out the initramfs dropping them.

    The reports here and on #8126 do not agree on a fix. One says the units plus Preserve=1 fixed it. One says Preserve=1 froze the machine, and only the units plus Preserve=0 worked. One says Preserve=0 with the units off corrupted video memory on every resume. Each changed several settings at once on different hardware. The can't alloc VA space errors in this report are an address-space allocation failure after resume, which is not the same thing as lost video memory. A suspend cycle needs real NVIDIA hardware, and none was available, so nothing was reproduced.

    Turning the units on in nvidia.sh would also override the driver package's own choice for every NVIDIA install. It would interact with hibernate on early-KMS systems (#8352, #10039). That is a decision for the maintainer, not a defect fix, so no pull request was opened.

    What would decide it, from an affected open-module machine, gathered with nothing changed from a stock install:

    • cat /proc/driver/nvidia/params | grep -E 'PreserveVideoMemoryAllocations|UseKernelSuspendNotifiers|TemporaryFilePath', run after a reboot, so we see what the loaded driver actually uses rather than what the files say.
    • systemctl is-enabled nvidia-suspend nvidia-resume nvidia-hibernate, and ls /etc/modprobe.d /usr/lib/modprobe.d.
    • journalctl -b -k covering the suspend and the failing resume.
    • Then the same resume with only the three units enabled and nothing else changed.

    Second opinion: Codex Medium reviewed the same facts. It agreed the root cause is unproven, that enabling the units is a design decision rather than a contained fix, and that it would not open a pull request yet. It added a point from NVIDIA's 610.57.04 open-module source, not checked here: the notifier path counts as the procfs suspend that Preserve=1 requires, and the extra resume the package's system-sleep hook writes is a no-op once the GPU is running. If so, the stock combination is not broken by design, and a real failure there would be a driver bug rather than a missing unit. Its agreement is not guaranteed to be independent of this review.

    This now waits on the maintainer, who decides whether Omarchy should override the driver package here. The readings above from an affected machine would let that decision rest on evidence.

  6. adamlrutledge commented on Oct 11, 2026

    @adamlrutledge
    adamlrutledge
    on Oct 11, 2026

    Its fixed with no issues so far after a week!! Check it out below and hope this helps some one

    Update: no drops for 7 days after switching to Omarchy Edge + the CachyOS BORE kernel

    Before the changes, the GPU fell off the bus (pciehp: Link Down on 00:03.1, then Xid 79) on 09-20, 09-24 and 10-04. Since the changes on 10-04 there have been no drops: 7 days, ~16 boots, with gaming and the card allowed to power down when idle (power/control=auto). It's early, and several things changed at once, so I can't say which one helped.

    What I changed:

    Switched Omarchy from the Stable to the Edge update channel and ran a full update. That brought:
    nvidia-open 610.57.04 → 615.71.09 (now 615.78.08)
    linux-firmware 20260810 → 20260916 (includes newer NVIDIA GSP firmware)
    linux-omarchy 7.2.5-3 → 7.2.5-4, systemd 262, mesa 26.2.4, hyprland 0.56.2-4, supergfxctl 5.2.7-3

Installed the CachyOS BORE kernel from the AUR (7.2.9, now 7.2.9-2), keeping linux-omarchy as a fallback:

yay -S linux-cachyos-bore linux-cachyos-bore-headers

Gotcha: yay installed the kernel before the headers, so the NVIDIA DKMS module and the UKI failed on the first try. After the headers were in, this fixed it:

sudo limine-mkinitcpio linux-cachyos-bore

Made it the default boot entry in Limine. I added this to /etc/default/limine:

BOOT_ORDER="linux-cachyos-bore, *, *fallback, Snapshots"

then ran sudo limine-update.

Removed my earlier workaround. I had a udev rule plus a supergfxd drop-in forcing power/control=on on AC. It didn't help (the 10-04 drop happened with the card awake), so the card is back on the default auto.

Not related to the drop: I disabled nvidia-suspend/resume/hibernate.service, since 595+ open modules use UseKernelSuspendNotifiers=1. That didn't change anything below.

    Unchanged: no kernel parameters (no pcie_aspm=off). ASPM is already disabled on the link. Hybrid mode via supergfxctl, BIOS GA403WW.310.

    Still seeing (separate issue): if I suspend with a game running on the dGPU, I get Xid 13 on resume, then Xid 31 (MMU fault, CE4_PBDMA0, name=modprobe) + Xid 154 (OS Reboot). The card stays on the bus. This looks like the known 595.71+ resume regression (NVIDIA/open-gpu-kernel-modules#1322). Workaround: quit games before suspending.

    Laptop: ASUS ROG Zephyrus G14 (GA403), RTX 5080 Laptop GPU, Omarchy (Arch), Hyprland.

  7. houtvongsak commented on Oct 22, 2026

    @houtvongsak
    houtvongsak
    on Oct 22, 2026

    Stock-state readings from an affected open-module machine, as requested above. Nothing changed from a stock install (no manual modprobe or unit changes).

    Hardware: ASUS hybrid laptop, AMD Radeon 680M (Rembrandt, amdgpu) + RTX 3060 Mobile (GA106M), nvidia-open-dkms / nvidia-utils 615.78.08-1, gpu-screen-recorder 6.1.4-1, Omarchy 4.0.6-1, linux-omarchy 7.2.8-9, Hyprland 0.56.2-4, mem_sleep = [s2idle] (only option).

    Live driver params (after reboot):

    PreserveVideoMemoryAllocations: 1
UseKernelSuspendNotifiers: 1
TemporaryFilePath: "/var/tmp"

    $ systemctl is-enabled nvidia-suspend nvidia-resume nvidia-hibernate
disabled disabled disabled
$ ls /etc/modprobe.d /usr/lib/modprobe.d
/etc/modprobe.d:      hid_apple.conf  nvidia.conf  omarchy-usb-autosuspend.conf
/usr/lib/modprobe.d:  bluetooth-usb.conf  gsr-nvidia.conf  nvidia-utils.conf  README  systemd.conf

    So: notifiers on, Preserve=1 (from gsr-nvidia.conf), units off — the stock combination described above.

    Failing resume (2026-10-22, journalctl -b -1 -k): two s2idle cycles at 09:59:18–09:59:23. After resume the dGPU logs repeated MMU/TLB failures:

    NVRM: GPU0 kgmmuInvalidateTlb_GM107: TLB invalidation failed waiting for prior invalidate (status=0x00000065), vaspaceFlags 0x84004020, scope 0x2, GFID 0
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Generic Error: Invalid state [NV_ERR_INVALID_STATE] (0x00000040) returned from mmuWalkUnmap(...)

    The iGPU then stalls (amdgpu 0000:07:00.0: Fence fallback timer expired on ring sdma0, 132 times), Hyprland exits, and its teardown oopses in nvidia_modeset:

    BUG: unable to handle page fault for address: 0000000000005320
RIP: 0010:nvUpdateFlipEvoHwState+0x69f/0xb50 [nvidia_modeset]
 drm_fb_helper_restore_fbdev_mode_unlocked
 drm_fbdev_client_restore
 drm_client_dev_restore
 drm_release
 __fput
 task_work_run
 do_exit
Fixing recursive fault but reboot is needed!

    Black screen, hard reboot required.

    Earlier occurrences on this machine (same stock config, from the journal):

    • 2026-10-03, driver 610.57.04: oops in ttm_lru_bulk_move_tail [ttm], Comm: systemd-sleep
    • 2026-10-04, driver 610.57.04: oops in nv_restore_user_channels [nvidia], Comm: systemd-sleep
    • 2026-10-15: oops in _mapInsertBase [nvidia] (no suspend in that boot, may be unrelated)

    So it reproduces on 615.78.08 as well as 610.57.04, and on a hybrid AMD + NVIDIA laptop with s2idle.

    Next: I'll enable only nvidia-suspend, nvidia-resume and nvidia-hibernate (nothing else changed), run suspend/resume cycles, and report back here with the result.

    Filed by Claude Opus 5.5 via Claude Code.

  8. omarchybot commented on Oct 22, 2026

    @omarchybot
    omarchybot
    on Oct 22, 2026
    Collaborator

    Thanks, @houtvongsak. These are the readings that were asked for, from a stock install, and they settle part of the question.

    What they establish: the failure happens with the stock combination: kernel suspend notifiers on, PreserveVideoMemoryAllocations at 1, and the three sleep units off. It happens on 615.78.08 as well as 610.57.04, so the newer driver did not clear it on this machine. Preservation is not missing, which rules out one of the earlier theories. PreserveVideoMemoryAllocations defaults to automatic, so it is on whenever the notifiers are, whether or not gpu-screen-recorder's file is present. Removing that file alone would not turn it off.

    What they do not establish: that the disabled units are the cause. NVIDIA documents this combination as the supported one for the open modules, with the units meant for the proprietary driver. The oops in nv_restore_user_channels under systemd-sleep shows the driver's restore ran in kernel sleep context and failed inside the driver. It does not show that a unit would have prevented it. The amdgpu fence timeouts on sdma0 also keep the hybrid side in scope: from these excerpts, the iGPU stalling could be a cause or a consequence of the NVIDIA MMU failure. The later nvidia_modeset oops during Hyprland's exit looks like damage after the fact rather than where it started.

    What decides it is the test you described: only the three units enabled, nothing else changed. When you report it, these would make the result readable:

    • journalctl -b -u nvidia-suspend -u nvidia-resume for that boot, to show the units actually ran on each cycle.
    • How many suspend cycles it survived. The earlier failures were days apart, so a single clean resume would not tell us much.
    • cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status just before suspending, adjusted to the dGPU's address from lspci -D | grep -i nvidia, so we know whether the dGPU was asleep or awake when the machine suspended.

    Nothing was reproduced here: a suspend cycle needs real NVIDIA hardware. No pull request is open that enables these units on the open-module path, and install/hardware/nvidia.sh on quattro still does not touch them.

    Second opinion: Codex Medium and muse-spark-1.3 (thinking high) reviewed this reading. Both agreed it still needs the units-only result. Both narrowed what the restore oops can be said to show. Codex pointed to NVIDIA's documented automatic default for preservation. Muse-spark raised the hybrid iGPU stall and the dGPU's runtime power state. Their agreement is not guaranteed to be independent of this review.

    This waits on your units-only result. After that, the maintainer decides whether Omarchy should override the driver package's choice here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions