Meteor Lake Linux suspend fix — i915.enable_psr=0

TL;DR — Intel Meteor Lake laptops (Core Ultra 100/200) on the i915 driver freeze on Linux suspend and on a few minutes of idle, because forced eDP PSR (Panel Self Refresh) wedges the display PHY on exit. The fix is one kernel parameter:

i915.enable_psr=0

Confirmed on a ThinkPad P1 Gen7 (Core Ultra 9 185H, RTX 4070, Samsung OLED). The same class of freeze reproduced on a T480s with the same forced config — it's configuration, not silicon.

---

I held the power button down more than 300 times on this machine.

ThinkPad P1 Gen7, Intel Core Ultra 9 185H (Meteor Lake), kernels 6.x through 7.x. Two symptoms, two years. Every suspend ended in a freeze on resume — power LED on, machine dead, hard shutdown. And on top of that: leave the screen static for ~5 minutes and the whole machine would lock up without any suspend at all.

I chased the wrong parameter for most of that time. This includes the wrong turn, because it's instructive.

Symptoms — so you know you're in the right place

• Freeze on resume from suspend — power LED on, unresponsive, hard shutdown required.
• Idle freeze with no suspend — a static screen ~5 min and the machine locks. This is the tell. A pure suspend bug doesn't freeze you while you're sitting there.
• It looks like a dead keyboard — input dies while the rest seemed alive. It is not a keyboard bug.
• No logs from the failed attempt — the freeze happens before the journal flushes.
• Persists across kernel versions (6.x and 7.x).
• Works fine on Fedora, Ubuntu, and Kali out of the box — and that is the whole clue.

Hardware that fits: Meteor Lake laptops on the i915 driver, especially with an eDP OLED panel.

Root cause: forced PSR wedges the eDP PHY on exit

Panel Self Refresh lets the panel hold its own image so the display engine can stop scanning out. Power win — when it works. On this machine it doesn't.

The internal eDP panel (Samsung SDC OLED) advertises PSR1 only — no PSR2, no Panel Replay. My Arch cmdline forced i915.enable_psr=2, but the panel dictates the level: the kernel negotiates down and runs PSR1 regardless. So I configured one thing and was running another.

PSR auto-enters on a static frontbuffer (the idle freeze) and on s2idle (the resume freeze). The failure is on PSR exit: the driver must relock the Meteor Lake C10 PHY, and it wedges. Eight instrumented cycles all failed at the identical point:

Failed to bring PHY A to idle
[CONNECTOR:eDP-1] commit wait timed out
vblank wait timed out   (in i915_drm_resume)
pixel_rate expected 572010 found 65082

Why it looks like a keyboard bug: the stuck DRM worker holds the DRM modeset lock while waiting for a vblank that never comes. Every GPU/compositor task — including input delivery — queues behind that lock. The serio IRQs still tick in hardware; userspace just can't process them. One mechanism, two triggers, total lockup.

The fix

i915.enable_psr=0

The panel is PSR1-only, so there's nothing to tune — only on or off, and on is what wedges the PHY.

Full cmdline (P1 Gen7, NVIDIA dGPU)

i915.enable_psr=0
i915.enable_dc=1 i915.enable_fbc=1 i915.enable_guc=3
i915.force_probe=7d55 xe.force_probe=!7d55
nvidia_drm.modeset=1 nvidia_drm.fbdev=1
nvidia.NVreg_DynamicPowerManagement=0x02
nvidia.NVreg_PreserveVideoMemoryAllocations=1
mem_sleep_default=s2idle intel_iommu=on iommu=pt

• i915.enable_psr=0 — the fix.
• i915.enable_dc=1 — enable_dc=0 breaks the display on this stack; pin it on.
• i915.enable_fbc=1, i915.enable_guc=3 — pinned for determinism across kernel updates.
• i915.force_probe=7d55 / xe.force_probe=!7d55 — bind the MTL iGPU to i915, block xe. Mandatory on dual-GPU MTL. 0x7d55 is the P1 Gen7 ID — check lspci -nn | grep VGA.
• nvidia.NVreg_PreserveVideoMemoryAllocations=1 — save/restore VRAM across suspend.
• mem_sleep_default=s2idle — MTL has no S3; never set deep.
• intel_iommu=on iommu=pt — only if you run VMs with GPU passthrough; drop otherwise.

iGPU-only (no dGPU)

i915.enable_psr=0 i915.enable_dc=1 i915.enable_fbc=1 mem_sleep_default=s2idle

Apply

GRUB — append to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then sudo grub-mkconfig -o /boot/grub/grub.cfg. systemd-boot — append to the options line in /boot/loader/entries/*.conf. No rebuild.

Prove it in 30 seconds, no reboot

Toggle PSR live via debugfs (DRI card index is usually 1 for the iGPU — check /sys/kernel/debug/dri/*/):

echo 1 | sudo tee /sys/kernel/debug/dri/1/i915_edp_psr_debug      # disable PSR at runtime
sudo cat /sys/kernel/debug/dri/1/i915_edp_psr_status              # -> PSR mode: disabled

Work normally, let the screen idle past 5 minutes, then sudo systemctl suspend and wake. If both freezes are gone, PSR was your cause — make it permanent with i915.enable_psr=0. Undo with echo 0 … or a reboot.

Run check-psr.sh to confirm the persistent state after reboot.

It's the config, not the chip or the kernel

The same hardware suspends fine on Fedora, Ubuntu, and Kali with stock settings. Arch's linux is the same mainline tree as Fedora's — so the kernel version was never the variable; the config layer was. None of those distros force PSR; I did. And a T480s (Whiskey Lake) froze the same way once it inherited the same cmdline — different GPU, different PHY, same bug. Copy the config that works; stop tuning blind.

What I got wrong (the wrong turn)

For months I was sure the culprit was PSR2 selective fetch. I set i915.enable_psr2_sel_fetch=0 and kept enable_psr=2, citing linux-surface #2158. It changed the failure timing, so I believed it. It was moot — the panel runs PSR1, so sel_fetch never engaged. The freezes continued. Disabling PSR outright is what ended them.

A parameter that shifts symptoms is not the same as one that fixes the cause. Verify against a known-good system.

Don't do these

• Never add any i8042.* boot param. On the keyboard theory I tried them — they run inside the s2idle resume path and hang the entire machine. It was never the keyboard.
• Never enable_psr=1/=2 on this panel — PSR1 is exactly what wedges the PHY.
• Never enable_dc=0 — breaks the display.
• Don't blacklist mei/mei_me — it binds to i915 as mei_gsc_proxy, downstream of the GPU, not causal.

Power

Disabling PSR forgoes a small self-refresh saving; in exchange the machine resumes and never locks while idle. Net on this box: >14 h idle runtime to full discharge (90 Wh battery, ~6 W average), Intel GPU RC6 ~99% at idle. If you want the PSR watt back, claw it from the idle path with a black-framebuffer blank (OLED black = pixels off), not by re-enabling the broken PSR. Keep DPMS panel power-off out of it — it drives the same PHY. See oled-protect for that side.

References

• linux-surface #2158 — PSR/sel_fetch discussion (sel_fetch is moot on PSR1-only panels)
• Arch BBS #313469 — kernel 7.x Meteor Lake regression thread

License

MIT — see LICENSE.