Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-867GitHub issuePublicDecided· Duplicate

Desktop becomes unresponsive after S3 resume: NVIDIA 610.57.04 modeset lock blocks Hyprland

Reported by chivopic · filed Sep 7, 2026 · open at source

Decided: Duplicate — decided by agents · verified 3 days ago.

This defect is tracked under R-131. This report describes the same defect, so it is folded under it in the inbox.

Earliest report of this defect: R-867 (filed Sep 7, 2026).

Decided by agents · verified· Oct 9, 2026

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaPartly in the audited arealock· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Desktop becomes unresponsive after S3 resume: NVIDIA 610.57.04 modeset lock blocks Hyprlandrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy 4.0.2-1; Hyprland 0.56.2-1; Quickshell 0.3.1-1; systemd 261.2-1
  • Lenovo Legion Y7000P IRX9 (83DG), Intel Core i7-14650HX
  • NVIDIA RTX 4060 Laptop (10de:28e0), nvidia-open-dkms and nvidia-utils 610.57.04-1
  • Kernel 7.1.9-arch1-2; BIOS NMCN34WW (2026-01-07)
  • HDMI-A-1 configured at 2560x1440@280, scale 1.5; current diagnostics show HDMI active and eDP off
  • Sleep mode: deep / ACPI S3

What's wrong?

After waking from suspend, the desktop becomes severely sluggish/unresponsive and requires a forced reboot. The previous boot's journal confirms that Hyprland remained blocked in NVIDIA modesetting for over four minutes after the kernel completed resume. Background kernel logging and network reconnection continued during this period.

This is a confirmed failure on an Omarchy installation, but the trace points toward an upstream NVIDIA driver issue; an Omarchy-specific root cause has not been established. Reporting the affected configuration and evidence for tracking.

Observed sequence

  1. Suspend the machine with the configuration above. The recorded request came from systemctl; the exact UI trigger is not known.
  2. Wake it from S3. In the captured incident, suspend began at 08:37 and wake occurred at 12:40 on 2026-09-07 (UTC+8).
  3. The desktop becomes sluggish/unresponsive and does not recover; a forced reboot is needed.

Expected: the desktop resumes normal responsiveness. Reproduction frequency is not yet quantified; no internal-panel-only or lower-refresh-rate comparison has been completed.

Journal evidence

08:37:23 omarchy-shell: secure=true
08:37:33 Finished NVIDIA system suspend actions.
08:37:33 PM: suspend entry (deep)
12:40:14 System returned from sleep operation 'suspend'.
12:40:14 PM: suspend exit
12:40:29 Finished NVIDIA system resume actions.
12:43:39 INFO: task Hyprland:1395 blocked for more than 122 seconds.
12:45:42 INFO: task Hyprland:1395 blocked for more than 245 seconds.

Selected kernel stack frames from 12:43:39 (the second report has the same relevant path):

task:Hyprland state:D
  down+0x53/0x70
  nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
  ApplyModeSetConfig+0x5ed/0xda0 [nvidia_modeset]
  nv_drm_atomic_apply_modeset_config+0x7b0/0x890 [nvidia_drm]
  drm_atomic_check_only+0x5c4/0x9f0
  drm_mode_atomic_ioctl+0x8f2/0xdb0
INFO: task Hyprland:1395 blocked on a semaphore likely last held by task nvidia-modeset/:907
task:nvidia-modeset/ state:R running task
  ? nvWriteGpEntry+0x115/0x3e0 [nvidia_modeset]
  ? nvPushSetObject+0xb1/0x170 [nvidia_modeset]
  ? nvPushKickoff+0x2c/0x50 [nvidia_modeset]
  ? PrefetchHelperSurfaceEvo+0x4df/0x6f0 [nvidia_modeset]
  ? nvDIFRPrefetchSurfaces+0x158/0x240 [nvidia_modeset]
  ? DifrPrefetchEventDeferredWork+0x16/0x30 [nvidia_modeset]
  ? nvkms_kthread_q_callback+0xe6/0x170 [nvidia_modeset]

Before entering suspend, NVIDIA DRM also logged Failed to register auto-value-update on pre-wait value for sync FD semaphore surface. Its causal relationship to the later hang is unknown.

Configuration and checks

Active /proc/driver/nvidia/params values:

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

The local /etc/modprobe.d/zz-nvidia-hibernate.conf explicitly sets NVreg_UseKernelSuspendNotifiers=0, overriding the packaged setting of 1. This is therefore not an unmodified default configuration. NVIDIA suspend/resume systemd services ran successfully. /var/tmp is disk-backed with approximately 248 GiB available at inspection. The suspend service has the packaged SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false drop-in.

omarchy-sleep-lock.service repeatedly restarted during the sleep operation and logged Failed to inhibit: The operation inhibition has been requested for is already running. The shell had already reported secure=true before suspend, so these messages alone do not establish a failed screen lock. They appear to come from the monitor restarting and trying to reacquire an inhibitor before the sleep operation finishes.

There are also spd5118 resume errors (-6), but resume completes and the persistent blocked task is in NVIDIA modesetting.

omarchy-debug --no-sudo --print was collected after reboot; relevant hardware and software details are included above. The diagnostic session did not change configuration or deliberately reproduce another freeze. No recording of the incident is available.

Related upstream reports

These are correlations, not proof of an identical underlying bug. No fix has been validated on this machine yet.

View raw text
### System details

- Omarchy 4.0.2-1; Hyprland 0.56.2-1; Quickshell 0.3.1-1; systemd 261.2-1
- Lenovo Legion Y7000P IRX9 (83DG), Intel Core i7-14650HX
- NVIDIA RTX 4060 Laptop (10de:28e0), nvidia-open-dkms and nvidia-utils 610.57.04-1
- Kernel 7.1.9-arch1-2; BIOS NMCN34WW (2026-01-07)
- HDMI-A-1 configured at 2560x1440@280, scale 1.5; current diagnostics show HDMI active and eDP off
- Sleep mode: deep / ACPI S3

### What's wrong?

After waking from suspend, the desktop becomes severely sluggish/unresponsive and requires a forced reboot. The previous boot's journal confirms that Hyprland remained blocked in NVIDIA modesetting for over four minutes after the kernel completed resume. Background kernel logging and network reconnection continued during this period.

This is a confirmed failure on an Omarchy installation, but the trace points toward an upstream NVIDIA driver issue; an Omarchy-specific root cause has **not** been established. Reporting the affected configuration and evidence for tracking.

### Observed sequence

1. Suspend the machine with the configuration above. The recorded request came from `systemctl`; the exact UI trigger is not known.
2. Wake it from S3. In the captured incident, suspend began at 08:37 and wake occurred at 12:40 on 2026-09-07 (UTC+8).
3. The desktop becomes sluggish/unresponsive and does not recover; a forced reboot is needed.

Expected: the desktop resumes normal responsiveness. Reproduction frequency is not yet quantified; no internal-panel-only or lower-refresh-rate comparison has been completed.

### Journal evidence

```text
08:37:23 omarchy-shell: secure=true
08:37:33 Finished NVIDIA system suspend actions.
08:37:33 PM: suspend entry (deep)
12:40:14 System returned from sleep operation 'suspend'.
12:40:14 PM: suspend exit
12:40:29 Finished NVIDIA system resume actions.
12:43:39 INFO: task Hyprland:1395 blocked for more than 122 seconds.
12:45:42 INFO: task Hyprland:1395 blocked for more than 245 seconds.
```

Selected kernel stack frames from 12:43:39 (the second report has the same relevant path):

```text
task:Hyprland state:D
  down+0x53/0x70
  nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
  ApplyModeSetConfig+0x5ed/0xda0 [nvidia_modeset]
  nv_drm_atomic_apply_modeset_config+0x7b0/0x890 [nvidia_drm]
  drm_atomic_check_only+0x5c4/0x9f0
  drm_mode_atomic_ioctl+0x8f2/0xdb0
INFO: task Hyprland:1395 blocked on a semaphore likely last held by task nvidia-modeset/:907
task:nvidia-modeset/ state:R running task
  ? nvWriteGpEntry+0x115/0x3e0 [nvidia_modeset]
  ? nvPushSetObject+0xb1/0x170 [nvidia_modeset]
  ? nvPushKickoff+0x2c/0x50 [nvidia_modeset]
  ? PrefetchHelperSurfaceEvo+0x4df/0x6f0 [nvidia_modeset]
  ? nvDIFRPrefetchSurfaces+0x158/0x240 [nvidia_modeset]
  ? DifrPrefetchEventDeferredWork+0x16/0x30 [nvidia_modeset]
  ? nvkms_kthread_q_callback+0xe6/0x170 [nvidia_modeset]
```

Before entering suspend, NVIDIA DRM also logged `Failed to register auto-value-update on pre-wait value for sync FD semaphore surface`. Its causal relationship to the later hang is unknown.

### Configuration and checks

Active `/proc/driver/nvidia/params` values:

```text
PreserveVideoMemoryAllocations: 1
UseKernelSuspendNotifiers: 0
TemporaryFilePath: "/var/tmp"
EnableS0ixPowerManagement: 0
```

The local `/etc/modprobe.d/zz-nvidia-hibernate.conf` explicitly sets `NVreg_UseKernelSuspendNotifiers=0`, overriding the packaged setting of 1. This is therefore not an unmodified default configuration. NVIDIA suspend/resume systemd services ran successfully. `/var/tmp` is disk-backed with approximately 248 GiB available at inspection. The suspend service has the packaged `SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false` drop-in.

`omarchy-sleep-lock.service` repeatedly restarted during the sleep operation and logged `Failed to inhibit: The operation inhibition has been requested for is already running`. The shell had already reported `secure=true` before suspend, so these messages alone do not establish a failed screen lock. They appear to come from the monitor restarting and trying to reacquire an inhibitor before the sleep operation finishes.

There are also `spd5118` resume errors (-6), but resume completes and the persistent blocked task is in NVIDIA modesetting.

`omarchy-debug --no-sudo --print` was collected after reboot; relevant hardware and software details are included above. The diagnostic session did not change configuration or deliberately reproduce another freeze. No recording of the incident is available.

### Related upstream reports

- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1289 — same driver version, RTX 4060 Laptop, and closely matching modeset/DIFR stack.
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1167 — display freezes shortly after resume with the same DIFR path.

These are correlations, not proof of an identical underlying bug. No fix has been validated on this machine yet.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • DuplicateR-131Decided by agents · verified · 2026-10-09 11:10 UTC