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.
linux-omarchy 7.2.5-3: NVIDIA GSP hangs during CS2 on AMD+RTX 4060 hybrid laptop
Reported by nuraly-v · filed Sep 19, 2026 · open at source
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?
- AreaOutside the audited area· 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
System
- ASUS TUF Gaming class hybrid laptop: AMD Ryzen (Rembrandt) + Radeon 680M iGPU, GeForce RTX 4060 (AD107, 8 GB) dGPU; display on the NVIDIA GPU (
nvidia-drmmodeset) - Omarchy 4.0.4-1; kernel
linux-omarchy 7.2.5-3(default since 4.0.4); stocklinux 7.2.3.arch1-3still installed nvidia-open-dkms+nvidia-utils610.57.04-1, DKMS-built and module-loading on both kernels (identical driver version)
What's wrong
CS2 (native Vulkan) started producing escalating NVIDIA GSP-class faults once linux-omarchy 7.2.5-3 became the default kernel. ~2 weeks of daily CS2 on the stock linux kernel with the same driver produced zero faults. The final event was a total system freeze requiring a hard reboot.
Event sequence
- Days on stock
7.2.3-arch1-3: daily clean CS2, no GPU faults. - Day 1 on
7.2.5-3-omarchy: two CS2 sessions, clean. - Day 2:
NVRM: Xid (PCI:0000:01:00): 109, name=cs2, errorString CTX SWITCH TIMEOUT, Info 0x2c014→ cs2 SIGSEGV inVKRenderThread(libtier0); GPU recovered. - Day 2 (later):
NVRM: Xid (PCI:0000:01:00): 175, name=VKRenderThread, Timeout after 75s of waiting for RPC response from GPU0 GSP! Expected function 103 (GSP_RM_ALLOC)→Xid 154, GPU recovery action ... PF FLR. Session ended shortly after. - Day 3: CS2 in game ~11 min; the journal stops mid-session with no panic, OOM, or NVRM text; on reboot journald reports "corrupted or uncleanly shut down". Total freeze, only a hard reboot recovered.
Expected
Stability matching the stock kernel.
Actual
Recurring NVIDIA GSP/context-switch hangs on linux-omarchy 7.2.5-3 with the identical driver version and DKMS build the stock kernel used without a single fault.
Notes
Not yet bisected against stock linux 7.2.3 on this machine (stock UKI still in Limine); can A/B on request.
Related
- #12490 — same kernel: total freeze regression, stock never did it
- #12403 — same kernel: GPU hang on first boot
- #12187 — NVIDIA hybrid laptop hard-freezes once linux-omarchy is default (different cause: no NVIDIA modules present)
- #12218 — NVIDIA freeze after 4.0.4 (cause unconfirmed)
Filed by big-pickle via opencode.
View raw text
### System - ASUS TUF Gaming class hybrid laptop: AMD Ryzen (Rembrandt) + Radeon 680M iGPU, GeForce RTX 4060 (AD107, 8 GB) dGPU; display on the NVIDIA GPU (`nvidia-drm` modeset) - Omarchy 4.0.4-1; kernel `linux-omarchy 7.2.5-3` (default since 4.0.4); stock `linux 7.2.3.arch1-3` still installed - `nvidia-open-dkms` + `nvidia-utils` 610.57.04-1, DKMS-built and module-loading on both kernels (identical driver version) ### What's wrong CS2 (native Vulkan) started producing escalating NVIDIA GSP-class faults once `linux-omarchy 7.2.5-3` became the default kernel. ~2 weeks of daily CS2 on the stock `linux` kernel with the same driver produced zero faults. The final event was a total system freeze requiring a hard reboot. ### Event sequence - Days on stock `7.2.3-arch1-3`: daily clean CS2, no GPU faults. - Day 1 on `7.2.5-3-omarchy`: two CS2 sessions, clean. - Day 2: `NVRM: Xid (PCI:0000:01:00): 109, name=cs2, errorString CTX SWITCH TIMEOUT, Info 0x2c014` → cs2 SIGSEGV in `VKRenderThread` (libtier0); GPU recovered. - Day 2 (later): `NVRM: Xid (PCI:0000:01:00): 175, name=VKRenderThread, Timeout after 75s of waiting for RPC response from GPU0 GSP! Expected function 103 (GSP_RM_ALLOC)` → `Xid 154, GPU recovery action ... PF FLR`. Session ended shortly after. - Day 3: CS2 in game ~11 min; the journal stops mid-session with no panic, OOM, or NVRM text; on reboot journald reports "corrupted or uncleanly shut down". Total freeze, only a hard reboot recovered. ### Expected Stability matching the stock kernel. ### Actual Recurring NVIDIA GSP/context-switch hangs on `linux-omarchy 7.2.5-3` with the identical driver version and DKMS build the stock kernel used without a single fault. ### Notes Not yet bisected against stock `linux 7.2.3` on this machine (stock UKI still in Limine); can A/B on request. ### Related - #12490 — same kernel: total freeze regression, stock never did it - #12403 — same kernel: GPU hang on first boot - #12187 — NVIDIA hybrid laptop hard-freezes once linux-omarchy is default (different cause: no NVIDIA modules present) - #12218 — NVIDIA freeze after 4.0.4 (cause unconfirmed) Filed by big-pickle via opencode.
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
Not linked to any known issue, other report or change yet.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 15:48 UTC