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: 30s NVMe stalls behind Meteor Lake VMD ("timeout, completion polled")
Reported by tmn73 · 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
ASUS ROG Zephyrus G16 GU605MI (BIOS GU605MI.329), Intel Core Ultra 9 185H, RTX 4070 Mobile, WD PC SN5000S 1TB (fw 34230100) behind Intel VMD 8086:7d0b, Omarchy 4.0.0.r2186, linux-omarchy 7.2.5-4
What's wrong?
Since I switched from linux-g14 6.18.9 to linux-omarchy 7.2.5 on Sep 16, the whole desktop freezes for up to 30s, several times a day. Nothing responds to clicks, and during some of them Hyprland pops the ANR dialog on Brave.
Each stall shows up in the kernel log as:
nvme nvme0: I/O tag 278 (9116) QID 1 timeout, completion polledSo the I/O did complete, the interrupt just never arrived, and the kernel waits the full io_timeout (30s) before it polls. Eg I screenshotted the ANR dialog at 20:19:15 and that line got logged at 20:19:31. Same thing again at 20:30:23, logged at 20:30:32.
The SSD sits behind the Meteor Lake VMD (8086:7d0b), the one with Intel erratum MTL016: the MSI can fire before the completion DMA lands. There's a patch on the list for it, not merged as far as I can tell: PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake
What's weird is how much worse it got on 7.2. Same machine, same BIOS, same SSD:
linux-g14 6.18.9 (Sep 8-15) Sep 11: 1, Sep 14: 1, Sep 15: 2, other days 0
linux-omarchy 7.2.5 (Sep 16-25) Sep 16: 11, Sep 17: 16, Sep 18: 12, Sep 23: 13, Sep 24: 1, Sep 25: 15I checked the IOMMU angle from #13030, it's not that here: iommu: Default domain type: Translated on both kernels. The only diff I found in dmesg is the HMB on this DRAM-less SSD: 32 MiB in 8 segments on 6.18, 64 MiB in 1 segment on 7.2. No idea if that matters. And I haven't tried stock linux 7.2.6 yet, so I can't say if it's 7.2 itself or the Omarchy config.
Would it make sense to carry that VMD patch in linux-omarchy until it lands upstream? Meanwhile, turning VMD off in the BIOS reportedly gets it to 0 and nvme_core.io_timeout=5 caps the stalls at ~5s (same bug on a Dell).
View raw text
### System details ASUS ROG Zephyrus G16 GU605MI (BIOS GU605MI.329), Intel Core Ultra 9 185H, RTX 4070 Mobile, WD PC SN5000S 1TB (fw 34230100) behind Intel VMD 8086:7d0b, Omarchy 4.0.0.r2186, linux-omarchy 7.2.5-4 ### What's wrong? Since I switched from linux-g14 6.18.9 to linux-omarchy 7.2.5 on Sep 16, the whole desktop freezes for up to 30s, several times a day. Nothing responds to clicks, and during some of them Hyprland pops the ANR dialog on Brave. Each stall shows up in the kernel log as: ``` nvme nvme0: I/O tag 278 (9116) QID 1 timeout, completion polled ``` So the I/O did complete, the interrupt just never arrived, and the kernel waits the full `io_timeout` (30s) before it polls. Eg I screenshotted the ANR dialog at 20:19:15 and that line got logged at 20:19:31. Same thing again at 20:30:23, logged at 20:30:32. The SSD sits behind the Meteor Lake VMD (8086:7d0b), the one with Intel erratum MTL016: the MSI can fire before the completion DMA lands. There's a patch on the list for it, not merged as far as I can tell: [PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake](https://lists.openwall.net/linux-kernel/2026/08/25/214) What's weird is how much worse it got on 7.2. Same machine, same BIOS, same SSD: ``` linux-g14 6.18.9 (Sep 8-15) Sep 11: 1, Sep 14: 1, Sep 15: 2, other days 0 linux-omarchy 7.2.5 (Sep 16-25) Sep 16: 11, Sep 17: 16, Sep 18: 12, Sep 23: 13, Sep 24: 1, Sep 25: 15 ``` I checked the IOMMU angle from #13030, it's not that here: `iommu: Default domain type: Translated` on both kernels. The only diff I found in dmesg is the HMB on this DRAM-less SSD: 32 MiB in 8 segments on 6.18, 64 MiB in 1 segment on 7.2. No idea if that matters. And I haven't tried stock `linux` 7.2.6 yet, so I can't say if it's 7.2 itself or the Omarchy config. Would it make sense to carry that VMD patch in linux-omarchy until it lands upstream? Meanwhile, turning VMD off in the BIOS reportedly gets it to 0 and `nvme_core.io_timeout=5` caps the stalls at ~5s ([same bug on a Dell](https://github.com/jmuzzi/dell-vmd-nvme-timeout-fix)).
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:29 UTC