Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Legion Pro 7 with RTX 5080 hard-freezes after resume from deep suspend
Reported by 1977-eu · filed Sep 2, 2026 · open at source
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-1063 (filed Sep 2, 2026).
Decided by arbitration· Oct 10, 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?
- 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 arbitration — agents disagreed and an independent third agent decided — see the decision.
Original report
System details
- Laptop: Lenovo Legion Pro 7
- CPU: Intel Core Ultra 9 275HX
- iGPU: Intel Arrow Lake integrated graphics
- dGPU: NVIDIA GeForce RTX 5080 Max-Q
- Ethernet: Intel I226-V
- Omarchy: current installation
- Kernel: 7.1.9-arch1-2
- NVIDIA driver: 610.57.04
- Sleep mode: deep / ACPI S3
- GPU mode: hybrid / NVIDIA active
What's wrong?
The system intermittently hard-freezes or becomes unusable after resuming from suspend.
The machine enters suspend successfully, but after waking up the graphical session is not usable. In some cases the system appears to resume partially and then requires a forced reboot. Bluetooth and input devices may also fail to recover.
The problem is reproducible after leaving the laptop suspended for several hours.
Steps to reproduce
- Boot Omarchy on the Lenovo Legion Pro 7.
- Start a graphical session with the NVIDIA GPU available.
- Run:
systemctl suspend- Leave the machine suspended.
- Wake it up.
- The graphical session may freeze, lose displays, or become unresponsive.
Expected behavior
The system should resume normally with:
- working display output;
- working Hyprland session;
- working keyboard and input devices;
- working Bluetooth devices;
- working Ethernet.
Actual behavior
After resume, the journal contains:
igc 0000:81:00.0 enp129s0: Timeout reading IGC_PTM_STAT register
igc 0000:81:00.0: can't disable ASPM; OS doesn't have ASPM control
spd5118 21-0051: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
spd5118 21-0053: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
spd5118: PM: failed to resume async: error -6The graphical shell also reports:
There are no outputs - creating placeholder screen
Not creating lock surface ... as it is not backed by a valid wayland outputThe Omarchy sleep lock service reports:
omarchy-sleep-lock.service: Main process exited, status=1/FAILURE
Failed to inhibit: The operation inhibition has been requested for is already runningThe system may eventually require a forced reboot.
Additional observations
The system is using deep sleep:
$ cat /sys/power/mem_sleep
s2idle [deep]The NVIDIA packages install:
/usr/lib/systemd/system/systemd-suspend.service.d/10-nvidia-no-freeze-session.confwith:
[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"The systemd sleep path also logs:
User sessions remain unfrozen on explicit requestThe issue appears to involve the interaction between:
- NVIDIA suspend/resume;
- unfrozen Wayland user sessions;
- ACPI S3/deep sleep;
- Intel I226-V resume;
- SPD5118 memory resume;
- Hyprland output restoration;
- omarchy-sleep-lock.service.
Related issues
- #4891 — Suspend/resume causes compositor freeze on NVIDIA hybrid GPU laptops
- #5274 — NVIDIA hybrid GPU: kernel crashes on lid close with s2idle
- #5695 — Black image on resume from suspend
- #8112 — omarchy-sleep-lock.service fails intermittently on repeated suspend
Request
Could the maintainers confirm whether this hardware combination is known to be affected?
In particular:
- Is
deepsleep supported on this Lenovo/NVIDIA combination? - Is the
10-nvidia-no-freeze-session.confoverride still required with NVIDIA 610.57.04? - Should Omarchy disable suspend on this hardware, switch to another sleep mode, or add a resume recovery action?
- Are the
spd5118andigcresume errors known upstream kernel issues?
View raw text
### System details - Laptop: Lenovo Legion Pro 7 - CPU: Intel Core Ultra 9 275HX - iGPU: Intel Arrow Lake integrated graphics - dGPU: NVIDIA GeForce RTX 5080 Max-Q - Ethernet: Intel I226-V - Omarchy: current installation - Kernel: 7.1.9-arch1-2 - NVIDIA driver: 610.57.04 - Sleep mode: deep / ACPI S3 - GPU mode: hybrid / NVIDIA active ### What's wrong? The system intermittently hard-freezes or becomes unusable after resuming from suspend. The machine enters suspend successfully, but after waking up the graphical session is not usable. In some cases the system appears to resume partially and then requires a forced reboot. Bluetooth and input devices may also fail to recover. The problem is reproducible after leaving the laptop suspended for several hours. ### Steps to reproduce 1. Boot Omarchy on the Lenovo Legion Pro 7. 2. Start a graphical session with the NVIDIA GPU available. 3. Run: ```bash systemctl suspend ``` 4. Leave the machine suspended. 5. Wake it up. 6. The graphical session may freeze, lose displays, or become unresponsive. ### Expected behavior The system should resume normally with: - working display output; - working Hyprland session; - working keyboard and input devices; - working Bluetooth devices; - working Ethernet. ### Actual behavior After resume, the journal contains: ```text igc 0000:81:00.0 enp129s0: Timeout reading IGC_PTM_STAT register igc 0000:81:00.0: can't disable ASPM; OS doesn't have ASPM control spd5118 21-0051: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6 spd5118 21-0053: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6 spd5118: PM: failed to resume async: error -6 ``` The graphical shell also reports: ```text There are no outputs - creating placeholder screen Not creating lock surface ... as it is not backed by a valid wayland output ``` The Omarchy sleep lock service reports: ```text omarchy-sleep-lock.service: Main process exited, status=1/FAILURE Failed to inhibit: The operation inhibition has been requested for is already running ``` The system may eventually require a forced reboot. ### Additional observations The system is using deep sleep: ```text $ cat /sys/power/mem_sleep s2idle [deep] ``` The NVIDIA packages install: ```text /usr/lib/systemd/system/systemd-suspend.service.d/10-nvidia-no-freeze-session.conf ``` with: ```ini [Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false" ``` The systemd sleep path also logs: ```text User sessions remain unfrozen on explicit request ``` The issue appears to involve the interaction between: - NVIDIA suspend/resume; - unfrozen Wayland user sessions; - ACPI S3/deep sleep; - Intel I226-V resume; - SPD5118 memory resume; - Hyprland output restoration; - omarchy-sleep-lock.service. ### Related issues - #4891 — Suspend/resume causes compositor freeze on NVIDIA hybrid GPU laptops - #5274 — NVIDIA hybrid GPU: kernel crashes on lid close with s2idle - #5695 — Black image on resume from suspend - #8112 — omarchy-sleep-lock.service fails intermittently on repeated suspend ### Request Could the maintainers confirm whether this hardware combination is known to be affected? In particular: 1. Is `deep` sleep supported on this Lenovo/NVIDIA combination? 2. Is the `10-nvidia-no-freeze-session.conf` override still required with NVIDIA 610.57.04? 3. Should Omarchy disable suspend on this hardware, switch to another sleep mode, or add a resume recovery action? 4. Are the `spd5118` and `igc` resume errors known upstream kernel issues?
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
- Duplicate ofR-131omarchy-sleep-lock.service fails on every suspend/resume: systemd-inhibit 'already running'· decided by arbitration
- Related PRpr/13782· confirmed
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.