Proof Portal

Sign in
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-696GitHub issuePublicDecided· Out of scope

Deep S3 suspend never resumes on Intel Raptor Lake-P (i915) after kernel 7.2.3-arch1-3 update — hard hang, requires power cycle

Reported by ukkit · filed Sep 11, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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

Deep S3 suspend never resumes on Intel Raptor Lake-P (i915) after kernel 7.2.3-arch1-3 update — hard hang, requires power cyclerevision 1 · captured 2026-09-28 21:23 UTC via poll

System unresponsive overnight — suspend never resumed (kernel 7.2.3-arch1-3, i915)

Summary

Laptop was unresponsive from the night of 2026-09-10 until manually power-cycled
the next morning. Journal evidence shows the machine suspended cleanly on lid
close and then simply never resumed or logged again — consistent with a
suspend/resume hang, first seen right after a kernel update. The same GPU/kernel
combo went through 5 clean suspend→resume cycles over the prior two days on the
previous kernel with zero related warnings, so this looks like a regression
introduced by the 7.2.3-arch1-3 kernel build (i915 driver) rather than a
config or hardware issue.

Expected behavior

Closing the lid suspends the laptop (S3 "deep" sleep); opening the lid /
pressing a key resumes it normally, as it has for the last several days.

Actual behavior

Laptop suspended on lid close and did not resume. It was unresponsive for
roughly 8.5 hours until manually power-cycled.

System details

  • Omarchy: 4.0.3-1
  • Kernel: 7.2.3-arch1-3 (updated in place from 7.1.9-arch1-2 at 17:55 on

2026-09-10, booted into the new kernel at 18:07)
- linux-firmware: 20260810-2
- Machine: Lenovo ThinkBook 14 G9 IRL, BIOS SRCN22WW (2025-11-18)
- CPU: Intel Core 7 240H (Raptor Lake)
- GPU: Intel Raptor Lake-P integrated graphics [8086:a7ab], driver i915
(an xe driver is also available for this hardware — not currently in use)
- Kernel cmdline (relevant flags already in place from a prior, separate
suspend fix): mem_sleep_default=deep ec_no_wakeup=1
- Desktop: Hyprland 0.56.2, SDDM

Steps to reproduce

  1. Update system, including a kernel bump to 7.2.3-arch1-3, and reboot into it.
  2. Use the laptop normally for a while.
  3. Close the lid to suspend.
  4. Attempt to resume (open lid / press key) — does not respond.

Not yet confirmed to reproduce deterministically on every suspend on this
kernel (only one suspend attempt was made on 7.2.3-arch1-3 before this
report), but it failed on the very first attempt after the kernel update.

Evidence (journalctl, previous boot)

Kernel updated and initramfs/UKI rebuilt:

[2026-09-10T17:55:20+0530] pacman: kernel package upgrade, mkinitcpio rebuild for 7.2.3-arch1-3

Booted into new kernel at 18:07. About 50 minutes later, an i915 driver error
appeared that had never occurred on the previous kernel:

Sep 10 18:57:37 almora kernel: i915 0000:00:02.0: [drm] *ERROR* Unclaimed access detected prior to suspending

Lid closed, suspend initiated normally:

Sep 10 22:05:18 almora systemd-logind[998]: Lid closed.
Sep 10 22:05:18 almora systemd-logind[998]: Suspending...
Sep 10 22:05:23 almora systemd[1]: Starting System Suspend...
Sep 10 22:05:23 almora systemd-sleep[2108100]: Successfully froze unit 'user.slice'.
Sep 10 22:05:23 almora systemd-sleep[2108100]: Performing sleep operation 'suspend'...
Sep 10 22:05:23 almora kernel: PM: suspend entry (deep)

This is the last line ever logged for that boot. No PM: suspend exit,
no further kernel or userspace log lines at all. journald is in persistent
mode (/var/log/journal present), so this is a genuine halt, not a lost-log
artifact. The next journal entry is a fresh boot at 06:46:42 the next morning,
with no clean-shutdown record for the prior session (consistent with a hard
power-off/on).

Comparison with the previous kernel (7.1.9-arch1-2)

Over the prior ~2 days on 7.1.9-arch1-2, the same laptop completed 5 clean
suspend→resume cycles with matching PM: suspend entry / PM: suspend exit
pairs, and zero occurrences of the "Unclaimed access detected prior to
suspending" i915 warning:

Sep 08 13:38:29 kernel: PM: suspend entry (deep)
Sep 08 13:40:11 kernel: PM: suspend exit
Sep 08 14:07:15 kernel: PM: suspend entry (deep)
Sep 08 15:42:28 kernel: PM: suspend exit
Sep 08 21:32:45 kernel: PM: suspend entry (deep)
Sep 08 21:55:20 kernel: PM: suspend exit
Sep 08 22:27:00 kernel: PM: suspend entry (deep)
Sep 09 17:22:08 kernel: PM: suspend exit
Sep 09 22:44:26 kernel: PM: suspend entry (deep)
Sep 10 08:55:51 kernel: PM: suspend exit

This is a genuinely new symptom that only appeared after the 7.2.3-arch1-3
kernel update, on the very first suspend attempted under that kernel.

Not the cause

This is a different failure mode from an earlier, already-resolved lid-close
battery-drain issue on this machine, which was fixed by forcing S3 via
mem_sleep_default=deep (that flag is still in place and is not implicated
here — the machine did correctly enter S3 "deep" suspend this time; it just
never came back out of it).

Related issues

No exact duplicate found after searching both basecamp/omarchy and
omacom/omarchy for suspend, i915, "unclaimed access", "Raptor Lake",
7.2.3, "never wakes"/"never resumes", ThinkBook, and related phrasing.
Closest matches, none of which are on Intel i915:

  • [omacom/omarchy#5277](https://github.com/omacom/omarchy/issues/5277) —

*System hard-freeze on suspend with hyprlock active — no resume, requires
hard reboot.* Same top-level symptom: freeze right at suspend entry, dead
until a hard power cycle, no further kernel logs because interrupts are
disabled past PM: suspend entry. Root cause there is NVIDIA-specific: the
driver hangs checkpointing GPU state while hyprlock is still actively
rendering during the cgroup-freeze window (a commenter hit the same thing
on AMD Ryzen AI Max). This report's own timeline shows a similar pattern —
live lock-screen/auth activity (fingerprint timeout → password unlock →
immediate re-lock) right through 22:05:18–22:05:23, the exact window
suspend entry occurred, plus the unexplained i915 "Unclaimed access" error
less than an hour earlier. Possible this is the same class of bug (GPU
still being touched as the suspend freeze kicks in) reaching i915 for the
first time.
- omacom/omarchy#6862 —
MacBookPro15,1 (T2): deep never resumes. Same "deep never resumes"
symptom, but T2 Mac / Thunderbolt-xHCI specific.
- omacom/omarchy#11245 —
Kernel 7.2.3: ELAN touchpad intermittently freezes. Confirms other users
are hitting regressions traced to the same 7.2.3 kernel shipped in 4.0.3,
though a different symptom.
- omacom/omarchy#5695 —
Black image on resume (sometimes ~60s freeze) after kernel bump to 7.0.
Precedent for a kernel bump breaking resume, but on an older kernel, and it
does eventually resume — this one never does.

Possible workarounds to test

  • Switch this GPU to the newer xe driver (available for Raptor Lake-P on

this kernel) instead of i915, since the "Unclaimed access" error is
specific to the i915 runtime-PM code path.
- Pin/downgrade to kernel 7.1.9-arch1-2 until a fixed kernel build is
available.

Diagnostics

Full omarchy-debug --no-sudo --print output (system info, package list,
current-boot warnings/errors) saved locally at:
~/omarchy-debug-2026-09-10.log

(Note: the documented dispatcher form omarchy debug --no-sudo --print did
not resolve to a command on this system — had to call the underlying
omarchy-debug binary directly.)

View raw text
# System unresponsive overnight — suspend never resumed (kernel 7.2.3-arch1-3, i915)

## Summary

Laptop was unresponsive from the night of 2026-09-10 until manually power-cycled
the next morning. Journal evidence shows the machine suspended cleanly on lid
close and then simply never resumed or logged again — consistent with a
suspend/resume hang, first seen right after a kernel update. The same GPU/kernel
combo went through 5 clean suspend→resume cycles over the prior two days on the
previous kernel with zero related warnings, so this looks like a regression
introduced by the 7.2.3-arch1-3 kernel build (i915 driver) rather than a
config or hardware issue.

## Expected behavior

Closing the lid suspends the laptop (S3 "deep" sleep); opening the lid /
pressing a key resumes it normally, as it has for the last several days.

## Actual behavior

Laptop suspended on lid close and did not resume. It was unresponsive for
roughly 8.5 hours until manually power-cycled.

## System details

- **Omarchy**: 4.0.3-1
- **Kernel**: 7.2.3-arch1-3 (updated in place from 7.1.9-arch1-2 at 17:55 on
  2026-09-10, booted into the new kernel at 18:07)
- **linux-firmware**: 20260810-2
- **Machine**: Lenovo ThinkBook 14 G9 IRL, BIOS SRCN22WW (2025-11-18)
- **CPU**: Intel Core 7 240H (Raptor Lake)
- **GPU**: Intel Raptor Lake-P integrated graphics [8086:a7ab], driver `i915`
  (an `xe` driver is also available for this hardware — not currently in use)
- **Kernel cmdline** (relevant flags already in place from a prior, separate
  suspend fix): `mem_sleep_default=deep ec_no_wakeup=1`
- **Desktop**: Hyprland 0.56.2, SDDM

## Steps to reproduce

1. Update system, including a kernel bump to 7.2.3-arch1-3, and reboot into it.
2. Use the laptop normally for a while.
3. Close the lid to suspend.
4. Attempt to resume (open lid / press key) — does not respond.

Not yet confirmed to reproduce deterministically on every suspend on this
kernel (only one suspend attempt was made on 7.2.3-arch1-3 before this
report), but it failed on the very first attempt after the kernel update.

## Evidence (journalctl, previous boot)

Kernel updated and initramfs/UKI rebuilt:
```
[2026-09-10T17:55:20+0530] pacman: kernel package upgrade, mkinitcpio rebuild for 7.2.3-arch1-3
```

Booted into new kernel at 18:07. About 50 minutes later, an i915 driver error
appeared that had never occurred on the previous kernel:
```
Sep 10 18:57:37 almora kernel: i915 0000:00:02.0: [drm] *ERROR* Unclaimed access detected prior to suspending
```

Lid closed, suspend initiated normally:
```
Sep 10 22:05:18 almora systemd-logind[998]: Lid closed.
Sep 10 22:05:18 almora systemd-logind[998]: Suspending...
Sep 10 22:05:23 almora systemd[1]: Starting System Suspend...
Sep 10 22:05:23 almora systemd-sleep[2108100]: Successfully froze unit 'user.slice'.
Sep 10 22:05:23 almora systemd-sleep[2108100]: Performing sleep operation 'suspend'...
Sep 10 22:05:23 almora kernel: PM: suspend entry (deep)
```

**This is the last line ever logged for that boot.** No `PM: suspend exit`,
no further kernel or userspace log lines at all. journald is in persistent
mode (`/var/log/journal` present), so this is a genuine halt, not a lost-log
artifact. The next journal entry is a fresh boot at 06:46:42 the next morning,
with no clean-shutdown record for the prior session (consistent with a hard
power-off/on).

## Comparison with the previous kernel (7.1.9-arch1-2)

Over the prior ~2 days on 7.1.9-arch1-2, the same laptop completed 5 clean
suspend→resume cycles with matching `PM: suspend entry` / `PM: suspend exit`
pairs, and **zero** occurrences of the "Unclaimed access detected prior to
suspending" i915 warning:

```
Sep 08 13:38:29 kernel: PM: suspend entry (deep)
Sep 08 13:40:11 kernel: PM: suspend exit
Sep 08 14:07:15 kernel: PM: suspend entry (deep)
Sep 08 15:42:28 kernel: PM: suspend exit
Sep 08 21:32:45 kernel: PM: suspend entry (deep)
Sep 08 21:55:20 kernel: PM: suspend exit
Sep 08 22:27:00 kernel: PM: suspend entry (deep)
Sep 09 17:22:08 kernel: PM: suspend exit
Sep 09 22:44:26 kernel: PM: suspend entry (deep)
Sep 10 08:55:51 kernel: PM: suspend exit
```

This is a genuinely new symptom that only appeared after the 7.2.3-arch1-3
kernel update, on the very first suspend attempted under that kernel.

## Not the cause

This is a different failure mode from an earlier, already-resolved lid-close
battery-drain issue on this machine, which was fixed by forcing S3 via
`mem_sleep_default=deep` (that flag is still in place and is not implicated
here — the machine did correctly enter S3 "deep" suspend this time; it just
never came back out of it).

## Related issues

No exact duplicate found after searching both `basecamp/omarchy` and
`omacom/omarchy` for `suspend`, `i915`, `"unclaimed access"`, `"Raptor Lake"`,
`7.2.3`, `"never wakes"/"never resumes"`, `ThinkBook`, and related phrasing.
Closest matches, none of which are on Intel i915:

- **[omacom/omarchy#5277](https://github.com/omacom/omarchy/issues/5277)** —
  *System hard-freeze on suspend with hyprlock active — no resume, requires
  hard reboot.* Same top-level symptom: freeze right at suspend entry, dead
  until a hard power cycle, no further kernel logs because interrupts are
  disabled past `PM: suspend entry`. Root cause there is NVIDIA-specific: the
  driver hangs checkpointing GPU state while hyprlock is still actively
  rendering during the cgroup-freeze window (a commenter hit the same thing
  on AMD Ryzen AI Max). This report's own timeline shows a similar pattern —
  live lock-screen/auth activity (fingerprint timeout → password unlock →
  immediate re-lock) right through 22:05:18–22:05:23, the exact window
  suspend entry occurred, plus the unexplained i915 "Unclaimed access" error
  less than an hour earlier. Possible this is the same class of bug (GPU
  still being touched as the suspend freeze kicks in) reaching i915 for the
  first time.
- [omacom/omarchy#6862](https://github.com/omacom/omarchy/issues/6862) —
  *MacBookPro15,1 (T2): deep never resumes.* Same "deep never resumes"
  symptom, but T2 Mac / Thunderbolt-xHCI specific.
- [omacom/omarchy#11245](https://github.com/omacom/omarchy/issues/11245) —
  *Kernel 7.2.3: ELAN touchpad intermittently freezes.* Confirms other users
  are hitting regressions traced to the same 7.2.3 kernel shipped in 4.0.3,
  though a different symptom.
- [omacom/omarchy#5695](https://github.com/omacom/omarchy/issues/5695) —
  *Black image on resume (sometimes ~60s freeze) after kernel bump to 7.0.*
  Precedent for a kernel bump breaking resume, but on an older kernel, and it
  does eventually resume — this one never does.

## Possible workarounds to test

- Switch this GPU to the newer `xe` driver (available for Raptor Lake-P on
  this kernel) instead of `i915`, since the "Unclaimed access" error is
  specific to the i915 runtime-PM code path.
- Pin/downgrade to kernel 7.1.9-arch1-2 until a fixed kernel build is
  available.

## Diagnostics

Full `omarchy-debug --no-sudo --print` output (system info, package list,
current-boot warnings/errors) saved locally at:
`~/omarchy-debug-2026-09-10.log`

(Note: the documented dispatcher form `omarchy debug --no-sudo --print` did
not resolve to a command on this system — had to call the underlying
`omarchy-debug` binary directly.)

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 11:43 UTC