> **Update — 12 October 2026:** The local workaround now persists through reboot via DKMS. The current boot records seven completed s2idle entry/exit cycles with elapsed intervals of approximately 5–63 hours. See the [extended-sleep test results and limitations](https://github.com/omacom/omarchy/issues/10754#issuecomment-6121892769). Resolution remains unconfirmed. The report below describes the initial tests.

### System details

Omarchy 4.0.2, Linux 7.1.9-arch1-2, Lenovo ThinkPad T14s Gen 2 AMD (model type 20XG), using s2idle.

### What's wrong?

Repeated sleep/wake attempts left the graphical session unusable. File operations and copying stopped working, and launching Codex produced database errors. Recovery required rebooting.

Expected behavior: after waking and unlocking, the desktop, file operations and applications should work normally.

The problem was observed during ordinary laptop sleep/wake use. A minimal deterministic reproducer and an exact failure rate have not been established.

### Temporary workaround and suspected cause

The matching Linux AMD PMC driver includes an existing firmware sleep workaround for the sibling ThinkPad model type 20XF, but omits type 20XG. A local test added 20XG to that model-matching table, selecting the same existing `quirk_s2idle_spurious_8042` workaround.

Specifically, in `drivers/platform/x86/amd/pmc/pmc-quirks.c`, the test added another entry equivalent to the 20XF entry, with:

```c
{
    .ident = "T14s Gen2 AMD",
    .driver_data = &quirk_s2idle_spurious_8042,
    .matches = {
        DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
        DMI_MATCH(DMI_PRODUCT_NAME, "20XG"),
    }
},
```

The PMC module was rebuilt for the running kernel and temporarily loaded. The kernel confirmed that the existing firmware workaround became active. The packaged module was retained; the test change currently disappears at reboot.

The existing upstream workaround addresses a Lenovo firmware interaction during NVMe resume. This suggests a Linux/firmware cause; an Omarchy-specific defect has not been established. Reporting the affected model and promising result for triage and possible documentation.

### Results and confidence

**Behavior has improved, but this is not yet confirmed fixed.**

- Two short instrumented suspend/resume cycles completed successfully. One woke early after roughly five seconds; the other recorded about one minute asleep, including hardware low-power residency.
- A later ordinary lid-close/wake also worked. The user reports normal operation afterward, and a third short suspend/resume cycle was recorded by the kernel.
- Post-wake storage checks passed. The user was able to continue using Codex.

The user initially could not tell whether an earlier locked screen represented sleep; that ambiguous observation is not counted as an extra successful test. The three counted cycles have kernel evidence of suspension.

The successful lid-close increases confidence, but all three sleeps were short. Longer sleeps, sustained everyday use, and behavior after reboot remain unverified. Some ACPI and graphics diagnostic warnings also remain. The result should be described as a promising temporary workaround, not a confirmed resolution or a general recommendation for other machines.

### References

- [Matching stable AMD PMC source](https://raw.githubusercontent.com/gregkh/linux/v7.1.9/drivers/platform/x86/amd/pmc/pmc-quirks.c).
- [Original upstream Lenovo NVMe resume workaround and rationale](https://github.com/torvalds/linux/commit/455cd867b85b53fd3602345f9b8a8facc551adc9).

Filed by GPT-6 via Codex at the user's request.