[SL3 Intel] S0ix breaks after reboot, works again after poweroff/hibernate

[cgernert]

Environment

• Surface Laptop 3 Intel
• i5-1035G7
• UEFI 19.101.140
• CachyOS
• currently kernel 7.2.2-1-cachyos
• only s2idle available

I ran into a weird S0ix issue on my SL3.

After a full shutdown and power-on, S0ix works fine. A 30 second suspend usually gives me around 29 seconds of S0ix residency.

I use this to test it:

D=/sys/kernel/debug/pmc_core
before=$(sudo cat "$D/slp_s0_residency_usec")
sudo rtcwake -m mem -s 30
after=$(sudo cat "$D/slp_s0_residency_usec")
echo $((after-before))

Typical result after a cold boot is around 29,000,000 µs.

After a normal reboot, the exact same test gives 0.

This is reproducible. A full poweroff followed by powering the laptop on again fixes it immediately.

Hibernation fixes it too. If S0ix is broken after a reboot, running systemctl hibernate and resuming brings it back to around 29 seconds again.

So for me it boils down to:

• poweroff + power on: S0ix works
• reboot: S0ix broken
• hibernate + resume: S0ix works

I also tried pm_test=platform and test_resume while in the broken state. Neither fixed it, so it seems to need an actual deeper platform power transition.

While broken, intel_pmc_core logs:

CPU did not enter SLP_S0!!! (S0ix cnt=0)

and slp_s0_debug_status shows, among other things:

PCIE_LOW_POWER No
XOSC_OFF No
PMC_ARC_PG_READY No

Package C10 still works and sits around 93-94%, so the CPU itself does reach deep idle.

I reproduced the same behavior with these kernels:

• 7.2.2-1-cachyos
• 7.2.2-arch1-1
• 6.18.48-1-lts
• 6.19.8-arch1-3-surface
• 6.14.10-arch1-1

I also tested two different NVMe drives, a Phison E13T and an SK hynix BC501, with no difference.

So this doesn't look kernel- or SSD-specific to me. My guess is that some platform state survives a warm reboot and prevents S0ix until the machine goes through a full poweroff or real hibernate cycle.

Current workaround is simply avoiding reboot if I want suspend to work properly.

I can provide more PMC output or test patches if useful.

[nekookto]

Seeing something related on a Surface Laptop 5 (15")... different SoC generation (Alder Lake, not Ice Lake) but possibly the same underlying mechanism, so leaving this here in case it's useful.

Environment

• Surface Laptop 5 (15")
• Alder Lake (12th gen Intel)
• BIOS: 24.104.143
• CachyOS, Limine bootloader
• Kernel: 6.19.8-arch1-3-surface (linux-surface)
• only s2idle available

Difference from the OP's report: for me, slp_s0_residency_usec reads 0 even after a full poweroff + manual power-on — not just after a warm reboot. Whatever resets it for you on poweroff doesn't seem to reset it here.

Possible lead — LPSS never power-gates:
substate_status_registers shows LPSS_PG_STS: 0 after a suspend/wake attempt, while nearly every other IP block (xHCI_PG_STS, SATA_PG_STS, SPA-SPD_PG_STS, etc.) reports 1 as expected. Package C10 residency is healthy (~93% in a short idle sample), so the CPU itself reaches deep idle fine - it's specifically LPSS staying powered that looks like the blocker.

Since LPSS carries the SAM UART link (surface_serial_hub), I suspect that device isn't fully quiescing before suspend, and that's holding the block open. This might tie into a separate symptom I'm seeing: full hard hangs on wake, showing as an instant suspend/re-entry loop in the journal:

PM: suspend entry (s2idle)
PM: suspend exit          <- same second
PM: suspend entry (s2idle) <- immediate retry, then log goes silent

No watchdog trace even with nowatchdog removed and pm_debug_messages=1 set — consistent with the platform retrying a failed low-power transition rather than hitting a normal software deadlock.

Additional evidence: surface_serial_hub produces zero suspend/resume-related log output across a full boot that included a suspend/wake cycle - the only line logged for it all boot is the initial firmware version at boot time:

kernel: surface_serial_hub serial0-0: SAM firmware version: 15.401.139

No output around PM: suspend entry/exit at all. Combined with LPSS_PG_STS: 0 staying ungated, this makes me suspect the SAM UART link isn't participating in the suspend sequence the way it needs to for LPSS to fully power down.

Happy to pull journalctl output around a surface_serial_hub suspend/resume cycle, or try unloading/reloading the driver around a suspend test, if that'd help narrow down whether it's the SAM link specifically.