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: kernel panic in idle task (Attempted to kill the idle task) on Alder Lake XPS 15 9520 — stock linux 7.2.3 stable
Reported by bkbatchelor · filed Sep 26, 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 details
Dell XPS 15 9520, Intel i7-12700H (Alder Lake), NVIDIA RTX 3050 Laptop (nvidia-open-dkms 610.57.04), Omarchy 4.0.4, linux-omarchy 7.2.5-3, intel-ucode 20260812, linux-firmware 20260810
What's wrong?
After switching from the stock Arch linux kernel to linux-omarchy 7.2.5-3 (first booted 2026-09-19), the machine hard-panicked twice within ~2 days, both times while a CPU was idle:
| Date | Kernel | Uptime at crash |
|---|---|---|
| 2026-09-22 01:26 | 7.2.5-3-omarchy | ~13.5 h (no log captured) |
| 2026-09-23 00:43 | 7.2.5-3-omarchy | ~22.7 h (captured via ramoops, below) |
In the preceding ~10 days on stock linux 7.2.3-arch1-3 (same NVIDIA driver, microcode and firmware; boots of up to 4 days) there were no panics or freezes. The only unclean endings in that period were manual power-offs (including the one used to reboot into linux-omarchy on 2026-09-19) and one boot that ended while suspended (battery). Nothing else changed in that window. See the stock kernel section at the end for the controlled A/B follow-up, which ran with ramoops enabled.
Panic (2026-09-23): the idle task on CPU 19 (an E-core) jumped to a garbage address. The call trace holds only common_startup_64, and the registers look like data, which points to memory corruption hitting the idle path (cpuidle/C-state resume?):
BUG: unable to handle page fault for address: ffffff53a92085f8
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 3a7b1b067 P4D 3a7b1b067 PUD 0
Oops: Oops: 0010 [#1] SMP NOPTI
CPU: 19 UID: 0 PID: 0 Comm: swapper/19 Tainted: G OE 7.2.5-3-omarchy #1 PREEMPT(full)
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Dell Inc. XPS 15 9520/0MWGD4, BIOS 1.43.0 07/23/2026
RIP: 0010:0xffffff53a92085f8
Code: Unable to access opcode bytes at 0xffffff53a92085ce.
RSP: 0018:ffffd5440023bf20 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000090 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00000086000000ea R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 00000036000000f4
R13: 0000000000000000 R14: 0000006700000036 R15: 0000000000000000
CR2: ffffff53a92085ce CR3: 00000003a6e22005 CR4: 0000000000f72ef0
Call Trace:
<TASK>
? common_startup_64+0x13e/0x151
</TASK>
Modules linked in: uas usb_storage uhid ccm nft_chain_nat nf_nat ... mac80211 snd_soc_core ... thunderbolt hid_apple nvidia ...
Kernel panic - not syncing: Attempted to kill the idle task!
Kernel Offset: 0x27e00000 from 0xffffffff81000000The taint comes from the NVIDIA open module. The same module version ran without problems on the stock kernel.
Kernel cmdline: zswap.enabled=0 rootfstype=btrfs rtc_cmos.use_acpi_alarm=1 resume=... initramfs_async=0 quiet splash (plus ramoops for capture)
A/B result: stock kernel
Since switching the default back to stock linux 7.2.3-arch1-3 on 2026-09-23 there have been no crashes over 3 days (85 h of uptime across 2 boot(s)), with the same NVIDIA driver, microcode, firmware and userspace. This points at a regression in linux-omarchy 7.2.5-3 (config or patches) and not at hardware or the NVIDIA module.
View raw text
### System details Dell XPS 15 9520, Intel i7-12700H (Alder Lake), NVIDIA RTX 3050 Laptop (nvidia-open-dkms 610.57.04), Omarchy 4.0.4, linux-omarchy 7.2.5-3, intel-ucode 20260812, linux-firmware 20260810 ### What's wrong? After switching from the stock Arch `linux` kernel to `linux-omarchy 7.2.5-3` (first booted 2026-09-19), the machine hard-panicked twice within ~2 days, both times while a CPU was idle: | Date | Kernel | Uptime at crash | |---|---|---| | 2026-09-22 01:26 | 7.2.5-3-omarchy | ~13.5 h (no log captured) | | 2026-09-23 00:43 | 7.2.5-3-omarchy | ~22.7 h (captured via ramoops, below) | In the preceding ~10 days on stock `linux 7.2.3-arch1-3` (same NVIDIA driver, microcode and firmware; boots of up to 4 days) there were no panics or freezes. The only unclean endings in that period were manual power-offs (including the one used to reboot into linux-omarchy on 2026-09-19) and one boot that ended while suspended (battery). Nothing else changed in that window. See the stock kernel section at the end for the controlled A/B follow-up, which ran with ramoops enabled. **Panic (2026-09-23)**: the idle task on CPU 19 (an E-core) jumped to a garbage address. The call trace holds only `common_startup_64`, and the registers look like data, which points to memory corruption hitting the idle path (cpuidle/C-state resume?): ``` BUG: unable to handle page fault for address: ffffff53a92085f8 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 3a7b1b067 P4D 3a7b1b067 PUD 0 Oops: Oops: 0010 [#1] SMP NOPTI CPU: 19 UID: 0 PID: 0 Comm: swapper/19 Tainted: G OE 7.2.5-3-omarchy #1 PREEMPT(full) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. XPS 15 9520/0MWGD4, BIOS 1.43.0 07/23/2026 RIP: 0010:0xffffff53a92085f8 Code: Unable to access opcode bytes at 0xffffff53a92085ce. RSP: 0018:ffffd5440023bf20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000090 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000086000000ea R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 00000036000000f4 R13: 0000000000000000 R14: 0000006700000036 R15: 0000000000000000 CR2: ffffff53a92085ce CR3: 00000003a6e22005 CR4: 0000000000f72ef0 Call Trace: <TASK> ? common_startup_64+0x13e/0x151 </TASK> Modules linked in: uas usb_storage uhid ccm nft_chain_nat nf_nat ... mac80211 snd_soc_core ... thunderbolt hid_apple nvidia ... Kernel panic - not syncing: Attempted to kill the idle task! Kernel Offset: 0x27e00000 from 0xffffffff81000000 ``` The taint comes from the NVIDIA open module. The same module version ran without problems on the stock kernel. **Kernel cmdline**: `zswap.enabled=0 rootfstype=btrfs rtc_cmos.use_acpi_alarm=1 resume=... initramfs_async=0 quiet splash` (plus ramoops for capture) ### A/B result: stock kernel Since switching the default back to stock `linux 7.2.3-arch1-3` on 2026-09-23 there have been **no crashes** over 3 days (85 h of uptime across 2 boot(s)), with the same NVIDIA driver, microcode, firmware and userspace. This points at a regression in `linux-omarchy 7.2.5-3` (config or patches) and not at hardware or the NVIDIA module.
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 18:46 UTC