Getting modern sleep (S0ix / “Modern Standby”) working on a Lenovo ThinkPad P1 Gen 7 (21KV) with Intel Meteor Lake and an NVIDIA RTX 4060 has been a significant undertaking. This post documents the hardware, the problems encountered, every fix applied, and the remaining blockers — in the hope it saves someone else the same multi-day debugging session.

Hardware

  • Laptop: Lenovo ThinkPad P1 Gen 7 (21KV0025UK)
  • CPU: Intel Core Ultra 7 165H (Meteor Lake)
  • GPU: NVIDIA RTX 4060 Max-Q Mobile (AD107M) — PRIME offload only, the Intel iGPU drives the display
  • OS: Fedora 43, kernel 6.19.x

The Problem: S0ix Does Not Work (Out of the Box)

Meteor Lake dropped legacy S3 sleep entirely. The only suspend option is S0ix (also called s2idle / Modern Standby), which requires every single device and subsystem to reach a low-power state. If any component stays awake, the CPU package cannot enter its deepest idle state and the laptop drains battery as if it were still running.

On this machine, over 35 PMC substate requirements were unmet out of the box. The root cause traces to the IOE die (PMC1) failing to power-gate, which appears to be a CSME firmware issue. The behaviour is even boot-dependent — some boots may partially work where others will not.

Kernel Parameters

The following kernel parameters were added to /etc/default/grub on the GRUB_CMDLINE_LINUX line:

pcie_aspm=force acpi.ec_no_wakeup=1 nmi_watchdog=0 snd_hda_intel.power_save=1
  • pcie_aspm=force — Force Active State Power Management on PCIe devices that don’t advertise support. Required because several Meteor Lake root ports won’t enter L1 otherwise.
  • acpi.ec_no_wakeup=1 — Prevent the Embedded Controller from generating spurious wakeups. ThinkPads are notorious for this.
  • nmi_watchdog=0 — Disable the NMI watchdog. It prevents the CPU from entering deep C-states.
  • snd_hda_intel.power_save=1 — Enable power saving on the HDA audio codec (1 second timeout).

ACPI Wake Sources

Several ACPI wake sources were causing immediate or spurious wake from suspend. A systemd service was created to disable them at boot:

# /etc/systemd/system/disable-wakeup-sources.service
# Disables: RP12, TXHC, TDM0, TRP0, TRP1

[Unit]
Description=Disable problematic ACPI wake sources
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'for src in RP12 TXHC TDM0 TRP0 TRP1; do echo $src > /proc/acpi/wakeup || true; done'

[Install]
WantedBy=multi-user.target

These sources relate to PCIe root ports and Thunderbolt controllers that would wake the machine immediately after suspend or on any USB-C cable event.

PMC LTR (Latency Tolerance Reporting) Overrides

Several devices were reporting LTR values that prevented the SoC from entering S0ix. These were overridden by writing to the PMC LTR ignore registers:

# LTR ignore indices:
# 1  = SOUTHPORT_B
# 3  = GBE (Gigabit Ethernet)
# 6  = ME (Management Engine)
# 8  = SOUTHPORT_C
# 25 = IOE_PMC

The GBE and ME entries are particularly important — the Intel Management Engine’s LTR blocks S0ix on virtually every Meteor Lake system unless ignored.

USB Subsystem

Two USB devices were holding the XHCI controller in D0, blocking package C-state entry:

  • The fingerprint reader
  • The Bluetooth adapter

Both were resolved by enabling USB autosuspend for all devices. Runtime PM was also explicitly enabled on the Thunderbolt host controller.

BIOS: Disable Intel AMT

Intel Active Management Technology (AMT) was enabled by default in the BIOS. This caused three PMC blockers:

  • KVMCC — KVM Controller for remote management
  • USBR0 — USB Redirection
  • SUSRAM — Suspend RAM used by AMT

Disabling AMT in the BIOS (Config → Network → Intel AMT) immediately cleared all three.

NVIDIA GPU Power Management

The NVIDIA GPU required extensive configuration to stop it from blocking low-power states:

Services Disabled

  • nvidia-powerd — Was causing the GPU to cycle between D3cold and D0 repeatedly
  • nvidia-persistenced — Kept a handle on the GPU, preventing it from entering D3cold

D3cold Enabled

Runtime power management and D3cold (full power off) were enabled for the NVIDIA GPU via /etc/modprobe.d/nvidia-pm.conf.

Proprietary Driver with GSP Firmware Disabled

The open-source nvidia-open kernel module was replaced with the proprietary NVIDIA driver, and GSP (GPU System Processor) firmware was disabled:

options nvidia NVreg_EnableGpuFirmware=0

This was necessary because the GSP firmware interfered with proper suspend/resume cycling on this GPU generation.

CUDA Isolation for Background Services

Any background service that might poke the GPU (e.g., monitoring tools, bots) was configured with:

Environment=CUDA_VISIBLE_DEVICES=

This prevents them from initialising the CUDA runtime and keeping the GPU in D0.

Other Fixes

  • intel-lpmd — Intel’s Low Power Mode Daemon was installed to help manage CPU power states on Meteor Lake.
  • SELinux — A custom /data partition had incorrect SELinux contexts, which was blocking systemd-logind from writing hibernate state. Relabelling the partition fixed it.

Hibernate: Broken

Hibernate (suspend-to-disk) does not work on this hardware combination and is unlikely to work any time soon.

The kernel panics during the hibernate image write phase. The NVIDIA driver’s pci_pm_freeze callback either fails or causes a kernel panic. This was tested with:

  • The open-source nvidia-open driver
  • The proprietary NVIDIA driver
  • GSP firmware on and off
  • Writing via /sys/power/state (procfs) directly
  • Skipping VT switch (no chvt)

All combinations result in a panic. This is a known upstream bug tracked at NVIDIA/open-gpu-kernel-modules Issue #922.

Do not attempt hibernate on this platform with NVIDIA drivers loaded.

What Still Blocks S0ix

Even after all the above fixes, S0ix is not fully achieved. The remaining blockers are in the PMC and relate to PLLs and fabric that cannot be controlled from userspace:

PMC1 (IOE Die)

  • SBR0–4 (Sideband Router instances)
  • FABRIC_PLL, TMU_PLL, BCLK_PLL, D2D_PLL, G5FPW PLLs, REF_PLL
  • VNN_SOC_REQ_STS

PMC0 (SoC Die)

  • LPSS — I2C4 stuck in D0 (likely the touchpad or touchscreen controller)
  • FABRIC_PLL, IOE_COND_MET
  • ITSS_CLK_SRC_REQ_STS
  • LSX_Wake4–7

These are firmware-level blockers. The IOE die (PMC1) issue in particular appears to require a CSME firmware update from Lenovo.

Things to Avoid

  • Do not restart systemd-logind — It will kill your entire GNOME session.
  • Do not use sleep hooks that run modprobe -r nvidia — gnome-shell holds nvidia_drm open; the unload will hang.
  • Do not use rtcwake -m mem — It bypasses the NVIDIA systemd suspend services and will likely result in a broken resume.
  • Do not attempt hibernate — Kernel panic (see above).

Configuration Files Modified

For reference, the following files were created or modified during this process:

  • /etc/default/grub — Kernel parameters
  • /etc/modprobe.d/nvidia-pm.conf — NVIDIA power management options
  • /etc/modprobe.d/nvidia-installer-disable-nouveau.conf — Nouveau blacklist
  • /etc/systemd/logind.conf.d/lid-suspend-then-hibernate.conf — Lid action configuration
  • /etc/systemd/sleep.conf — Sleep/hibernate configuration
  • /etc/systemd/system/disable-wakeup-sources.service — ACPI wake source disabling
  • /usr/lib/systemd/system-sleep/ollama-nvidia-hibernate.sh — Pre/post sleep hooks

Conclusion

Modern Standby on Meteor Lake with NVIDIA discrete graphics is a minefield. While many of the userspace-controllable blockers can be resolved, the core IOE die power-gating issue and the NVIDIA hibernate panic are firmware bugs that no amount of kernel tuning can fix. If you’re buying a Meteor Lake workstation for Linux, check the NVIDIA hibernate bug status and your vendor’s CSME firmware changelog before committing.

]]>