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-2100GitHub issuePublicDecided· Out of scope

AMD Lucienne (ThinkPad E15 Gen 3): reg-write failures start at a hibernate resume, hibernation writes degrade to worst-ever, final hibernate froze during image write (no image, silent journal end)

Reported by kraudy · filed Sep 29, 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

AMD Lucienne (ThinkPad E15 Gen 3): reg-write failures start at a hibernate resume, hibernation writes degrade to worst-ever, final hibernate froze during image write (no image, silent journal end)revision 1 · captured 2026-09-29 14:42 UTC via poll

System details

Omarchy 4.0.4-1; linux-omarchy 7.2.5-3; linux-firmware-amdgpu 20260810-2; Lenovo ThinkPad E15 Gen 3 (20YG003DUS), Ryzen 7 5700U / AMD Lucienne iGPU 1002:164c (Renoir, GC 9.3.0). Same machine as #11413.

Hibernation layout: LUKS + btrfs, 38G swapfile (/swap/swapfile, NOCOW, resume=/dev/mapper/root resume_offset=1919290), 38G zram at priority 100, Limine + UKI boot. ~30 successful hibernate/resume cycles per boot before the event.

What happened

This is a different failure from #11413 (which is the resume-phase compute-IB / drm_sched_job_arm oops, tracked upstream in drm/amd #5808). This one is at hibernation entry, silent, with no oops and no image written. It happened on the stock kernel with no local hooks installed (only keyboard-backlight and unmount-fuse in /usr/lib/systemd/system-sleep/ — the GFXOFF workaround from #11413 was not active).

Timeline from journalctl (single boot, Sep 20 14:17 → Sep 26 23:37):

  • Sep 22 11:40:09 — resume from a hibernation cycle. From this exact moment, amdgpu 0000:04:00.0: failed to write reg 28b4 wait reg 28c6 / 1a6f4 wait 1a706 spam starts and never stops: 328/day (Sep 22) → 626 → 822 → 612 → 798 (Sep 26), 3186 total. Earlier in the same boot: 0.
  • Sep 24–26 evenings — hibernation image-write times degrade monotonically to the slowest ever recorded on this machine (~30 prior cycles span 55–433 s at 20–100 MB/s): 365 s (Sep 24) → 473/505/558 s (Sep 25) → 572 s / 565 s at 16.7 MB/s (Sep 26).
  • Sep 26 23:37:20 — hibernate requested with video playing. 23:37:21: user.slice frozen, PM: hibernation: hibernation entry, Filesystems sync: 0.097 seconds — last journal line ever written. Screen frozen, audio stuck looping the last buffer. Hard power-off was done within a few minutes.
  • Sep 27 07:14 — next boot is a fresh boot; the kernel did not auto-resume ⇒ the swsusp image was never completed, so the attempt died inside hibernation entry (image prealloc/write), not at S4 entry or device suspend. Whether it was a true hang or merely the degraded ~10-min write interrupted by the power-off cannot be distinguished from logs — but every prior cycle in the same session completed, and the write path had been slowing down for days.
  • After reboot everything resets: 0 reg-write failures in the following 4 days, write times back to 107 s / 60.6 MB/s.

What I checked before filing

  • No duplicate found in this tracker for an entry-time image-write stall with preceding reg-write spam.
  • Not #8589 (G14 aborts during image creation, NVIDIA hybrid, HibernateMode=shutdown fixes it) and not #11413 — different phase and signature.
  • pstore empty; no OOM (free fine, swapfile 38G, image ~9.5G); journald had ~4G free.
  • Same "failed to write reg 28b4/1a6f4" pair as in #11413's history, but here it appeared without any local GFXOFF hook, on stock linux-omarchy 7.2.5-3, and started at a hibernate resume, not at entry.

Ask

Mostly flagging for visibility on Omarchy's target hardware: an hibernate-resume can apparently leave the GPU/system in a degraded state that worsens over days and ends with a hibernation that never completes, requiring a power cycle. Cross-referencing drm/amd #5808 where the Lucienne S4 investigation continues — happy to add this cycle's data there if it is useful to that thread.

Filed by GLM (glm-5.3-flash) via opencode.

View raw text
### System details

Omarchy 4.0.4-1; linux-omarchy 7.2.5-3; linux-firmware-amdgpu 20260810-2; Lenovo ThinkPad E15 Gen 3 (20YG003DUS), Ryzen 7 5700U / AMD Lucienne iGPU 1002:164c (Renoir, GC 9.3.0). Same machine as #11413.

Hibernation layout: LUKS + btrfs, 38G swapfile (`/swap/swapfile`, NOCOW, `resume=/dev/mapper/root resume_offset=1919290`), 38G zram at priority 100, Limine + UKI boot. ~30 successful hibernate/resume cycles per boot before the event.

### What happened

This is a **different failure from #11413** (which is the resume-phase compute-IB / `drm_sched_job_arm` oops, tracked upstream in drm/amd #5808). This one is at hibernation **entry**, silent, with no oops and no image written. It happened on the stock kernel with **no local hooks installed** (only `keyboard-backlight` and `unmount-fuse` in `/usr/lib/systemd/system-sleep/` — the GFXOFF workaround from #11413 was **not** active).

Timeline from `journalctl` (single boot, Sep 20 14:17 → Sep 26 23:37):

- **Sep 22 11:40:09** — resume from a hibernation cycle. From this exact moment, `amdgpu 0000:04:00.0: failed to write reg 28b4 wait reg 28c6` / `1a6f4 wait 1a706` spam starts and never stops: 328/day (Sep 22) → 626 → 822 → 612 → 798 (Sep 26), **3186 total**. Earlier in the same boot: 0.
- **Sep 24–26 evenings** — hibernation image-write times degrade monotonically to the slowest ever recorded on this machine (~30 prior cycles span 55–433 s at 20–100 MB/s): 365 s (Sep 24) → 473/505/558 s (Sep 25) → **572 s / 565 s at 16.7 MB/s (Sep 26)**.
- **Sep 26 23:37:20** — hibernate requested with video playing. 23:37:21: `user.slice` frozen, `PM: hibernation: hibernation entry`, `Filesystems sync: 0.097 seconds` — **last journal line ever written**. Screen frozen, audio stuck looping the last buffer. Hard power-off was done within a few minutes.
- **Sep 27 07:14** — next boot is a fresh boot; the kernel did **not** auto-resume ⇒ the swsusp image was never completed, so the attempt died inside hibernation entry (image prealloc/write), *not* at S4 entry or device suspend. Whether it was a true hang or merely the degraded ~10-min write interrupted by the power-off cannot be distinguished from logs — but every prior cycle in the same session completed, and the write path had been slowing down for days.
- After reboot everything resets: 0 reg-write failures in the following 4 days, write times back to 107 s / 60.6 MB/s.

### What I checked before filing

- No duplicate found in this tracker for an entry-time image-write stall with preceding reg-write spam.
- Not #8589 (G14 aborts during image creation, NVIDIA hybrid, `HibernateMode=shutdown` fixes it) and not #11413 — different phase and signature.
- `pstore` empty; no OOM (`free` fine, swapfile 38G, image ~9.5G); journald had ~4G free.
- Same "failed to write reg 28b4/1a6f4" pair as in #11413's history, but here it appeared **without any local GFXOFF hook**, on stock `linux-omarchy 7.2.5-3`, and started at a hibernate **resume**, not at entry.

### Ask

Mostly flagging for visibility on Omarchy's target hardware: an hibernate-resume can apparently leave the GPU/system in a degraded state that worsens over days and ends with a hibernation that never completes, requiring a power cycle. Cross-referencing drm/amd #5808 where the Lucienne S4 investigation continues — happy to add this cycle's data there if it is useful to that thread.

Filed by GLM (glm-5.3-flash) 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 20:10 UTC