Enginyeria

Arreglar la suspensió/represa a Meteor Lake: un paràmetre del kernel, un any tard

12 min lectura
Angel Sulev

Correcció, 22-09-2026. Quan vaig publicar això vaig assenyalar i915.enable_psr2_sel_fetch=0 com la solució. No ho era. El meu panell anuncia només PSR1, així que el selective fetch no va arribar mai a actuar — el paràmetre canviava el moment de la penjada, que és exactament per què me’l vaig creure durant mesos. El paràmetre que va acabar amb les penjades és i915.enable_psr=0. L’URL conserva el nom antic per no trencar els enllaços existents; tot el que hi ha a sota és la versió corregida, i he deixat el camí equivocat al final perquè és la part instructiva.

Vaig mantenir premut el botó d’engegada més de 300 vegades en aquesta màquina.

ThinkPad P1 Gen7, Intel Core Ultra 9 185H (Meteor Lake), del kernel 6.x al 7.x. Dos símptomes, no un. Cada suspensió acabava en penjada: LED d’engegada fix, màquina morta, apagada forçada. I a banda: deixar la pantalla quieta uns cinc minuts i la màquina sencera es bloquejava sense que hi hagués cap suspensió pel mig. Més d’un any de feina real en un portàtil que no sabia ni dormir ni estar-se quiet.

El segon símptoma és el que resol el cas, i el vaig ignorar durant mesos perquè ja havia decidit que això era una fallada de suspensió.

Símptomes — perquè sàpigues si ets al lloc correcte

  • Penjada en reprendre des de suspensió — LED encès, sense resposta, apagada forçada obligatòria.
  • Penjada en inactivitat, sense suspensió — pantalla quieta uns 5 minuts i la màquina es bloqueja. Aquesta és la pista. Una fallada purament de suspensió no et penja la màquina mentre hi estàs assegut treballant.
  • Sembla un teclat mort — l’entrada deixa de respondre mentre la resta sembla viva. No és una fallada del teclat, i perseguir-la com a tal és un parany al qual torno més avall.
  • Sense logs de l’intent fallit — journalctl -b -1 surt buit o truncat; la penjada arriba abans que el journal es bolqui a disc.
  • Persisteix entre versions del kernel — 6.x i 7.x, igual.
  • Funciona bé a Fedora, Ubuntu i Kali de sèrie. Aquesta és la pista sencera.

Maquinari que hi encaixa: qualsevol portàtil Meteor Lake (Intel Core Ultra 100 o 200) amb el driver i915, especialment amb panell eDP OLED. El P1 Gen7 està confirmat.

Causa arrel: el PSR forçat encalla el PHY eDP en sortir

Panel Self Refresh permet que el panell mantingui la seva pròpia imatge perquè el motor de display deixi d’escanejar. És un estalvi real d’energia quan funciona. En aquesta màquina no funciona.

El panell intern (Samsung SDC OLED) anuncia només PSR1 — ni PSR2 ni Panel Replay. La meva cmdline forçava i915.enable_psr=2, però el nivell el dicta el panell: el kernel negocia a la baixa i executa PSR1 igualment. Així que jo tenia configurada una cosa i n’executava una altra, que és com un any sencer tocant el botó equivocat es va mantenir plausible.

El PSR entra sol amb un frontbuffer estàtic — aquesta és la penjada en inactivitat — i amb s2idle, que és la penjada en reprendre. La fallada és a la sortida del PSR: el driver ha de tornar a enganxar el PHY C10 de Meteor Lake, i s’encalla. Vuit cicles instrumentats van fallar tots al mateix punt exacte:

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

Per què sembla una fallada del teclat. El worker de DRM encallat reté el modeset lock de DRM mentre espera un vblank que no arriba mai. Totes les tasques de GPU i del compositor s’encuen darrere d’aquest lock, i el lliurament d’esdeveniments d’entrada n’és una. Les interrupcions de serio continuen arribant per maquinari; simplement userspace no arriba mai a processar-les. Un mecanisme, dos disparadors, bloqueig total.

La solució

Mínim — afegeix això a la teva cmdline del kernel

i915.enable_psr=0 i915.enable_dc=1 i915.enable_fbc=1 mem_sleep_default=s2idle
  • i915.enable_psr=0 — la solució. El panell és només PSR1, així que no hi ha res a ajustar: encès és precisament el que encalla el PHY.
  • i915.enable_dc=1 — estats d’estalvi DC5/DC6. enable_dc=0 trenca el display en aquest stack; deixa’l fixat a 1.
  • i915.enable_fbc=1 — fixat per determinisme entre actualitzacions de kernel, no perquè arregli res.
  • mem_sleep_default=s2idle — Meteor Lake no té S3. No posis mai deep.

Amb dGPU NVIDIA (sèrie RTX)

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=0
mem_sleep_default=s2idle

i915.force_probe=7d55 i xe.force_probe=!7d55 assignen la iGPU Meteor Lake a i915 i bloquegen que el driver xe se la disputi. En un sistema de GPU dual això és obligatori. 0x7d55 és l’ID del P1 Gen7 — comprova el teu amb lspci -nn | grep VGA.

NVreg_DynamicPowerManagement=0x02 activa D3 de gra fi perquè la RTX s’apagui del tot en repòs. NVreg_PreserveVideoMemoryAllocations depèn del driver que facis servir. Amb els mòduls oberts (nvidia-open), desar i restaurar la VRAM en suspendre ja és automàtic, així que deixa’l a 0. L’1 és per al mòdul propietari, i la documentació de gestió d’energia d’NVIDIA diu que llavors necessita el mecanisme /proc/driver/nvidia/suspend i els serveis nvidia-suspend/nvidia-resume. Per saber quin tens: modinfo -F license nvidia. Si diu Dual MIT/GPL, és l’obert.

Amb pas de GPU a QEMU/KVM

i915.enable_psr=0 i915.enable_dc=1
intel_iommu=on iommu=pt
mem_sleep_default=s2idle

iommu=pt manté baix el cost de l’IOMMU per als dispositius de l’amfitrió. Deixa’l només si fas servir VMs amb pas de GPU; CUDA a bare metal no el necessita.

Com aplicar-ho

GRUB — afegeix a GRUB_CMDLINE_LINUX_DEFAULT a /etc/default/grub i després:

sudo grub-mkconfig -o /boot/grub/grub.cfg

systemd-boot — afegeix a la línia options a /boot/loader/entries/*.conf. Sense regenerar res.

Comprova-ho en 30 segons, sense reiniciar

No cal que em creguis ni que toquis el gestor d’arrencada per sortir de dubtes. El PSR es commuta en calent via debugfs. L’índex de targeta DRI acostuma a ser 1 per a la iGPU — mira /sys/kernel/debug/dri/*/:

echo 1 | sudo tee /sys/kernel/debug/dri/1/i915_edp_psr_debug      # desactiva PSR en calent
sudo cat /sys/kernel/debug/dri/1/i915_edp_psr_status              # -> PSR mode: disabled

Després treballa amb normalitat, deixa la pantalla quieta més de cinc minuts i fes un sudo systemctl suspend. Si totes dues penjades desapareixen, la teva causa era el PSR — fes-ho permanent amb i915.enable_psr=0. Es desfà amb echo 0, o reiniciant.

Commuta’l amb la pantalla activa, no en repòs: així forces una sortida neta del PSR en comptes de provocar-la des de just l’estat que intentes evitar.

Verificació després de reiniciar

# Comprovar que s2idle està seleccionat
cat /sys/power/mem_sleep          # s2idle entre claudàtors = seleccionat

# Comprovar que el paràmetre ha entrat
grep -o 'i915.enable_psr=[0-9]' /proc/cmdline

# Suspendre
sudo systemctl suspend
# Espera 10 segons. Prem el botó d'engegada un cop per despertar.

# Comprovació ràpida
journalctl -b | grep -E 'PM: suspend|resume'

PM: suspend entry seguit de PM: suspend exit amb uns segons de diferència vol dir que la suspensió ha funcionat. Si la màquina no respon després de prémer el botó, s’ha penjat. Abans de mantenir premut el botó d’engegada, prova la sortida del mateix kernel: Alt+PetSis, i després s, u, o — sincronitza, remunta en només lectura i apaga. En un ThinkPad sense tecla PetSis, mantén Alt primer, prem Fn+ImprPant, deixa anar aquestes dues i prem cada lletra sense deixar anar Alt. Després llegeix l’arrencada anterior:

journalctl -b -1 | grep -E 'PM: suspend|i915.*fail|PHY|flip_done|panic'

La signatura de la fallada de PSR és Failed to bring PHY A to idle i flip_done timed out. Si no hi veus cap error d’i915, tens un altre problema — mira la nota del final.

És la configuració, no el xip ni el kernel

El mateix maquinari suspèn bé a Fedora, Ubuntu i Kali amb els ajustos de sèrie. El linux d’Arch es compila del mateix arbre mainline que el de Fedora, així que la versió del kernel no va ser mai la variable — ho era la capa de configuració. Cap d’aquelles distros força el PSR. Jo sí.

I un T480s (Whiskey Lake) es va penjar igual tan bon punt va heretar la mateixa cmdline. Una altra GPU, un altre PHY, la mateixa fallada. Copia una configuració que funcioni abans de posar-te a ajustar a cegues.

Ajust d’energia — què fer un cop suspèn

Autosuspend d’USB — evita l’interruptor global

Jo tenia usbcore.autosuspend=-1 a la cmdline, que desactiva l’autosuspend d’USB per a tots els dispositius de la màquina. Funciona, i et costa bateria sense motiu. Activa l’autosuspend globalment a TLP i eximeix només els dispositius que no s’han d’adormir:

# /etc/tlp.conf
USB_AUTOSUSPEND=1
USB_DENYLIST="1050:0407 27c6:6594 04f2:b805"

Aquests IDs són una YubiKey (1050:0407), un lector d’empremta Goodix (27c6:6594) i una càmera integrada Chicony (04f2:b805). Busca els teus amb lsusb, i afegeix-hi adaptadors Bluetooth, lectors de targeta i qualsevol cosa que hagi de respondre a l’instant.

Treu usbcore.autosuspend=-1 un cop confirmis que la suspensió funciona, regenera la configuració de GRUB, reinicia i torna a provar.

TLP a Meteor Lake

CPU_DRIVER_OPMODE_ON_AC=active
CPU_DRIVER_OPMODE_ON_BAT=active
CPU_SCALING_GOVERNOR_ON_AC=powersave
CPU_SCALING_GOVERNOR_ON_BAT=powersave
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
PLATFORM_PROFILE_ON_AC=balanced
PLATFORM_PROFILE_ON_BAT=low-power

active és el mode correcte per a intel_pstate a MTL — no el passis a passive. El governador powersave amb intel_pstate no és el que el nom suggereix: continua pujant la freqüència quan cal, només que decideix millor quan.

Què costa realment desactivar el PSR

Mesurat en aquesta màquina amb i915.enable_psr=0:

  • Consum en repòs: ~6 W de sistema complet (upower, energy-rate)
  • Residència RC6 de la GPU Intel: ~99% (intel_gpu_top) — la iGPU està aparcada gairebé tota la finestra de repòs
  • Bateria: més de 14 h en repòs fins a descàrrega completa amb una bateria de 90 Wh

És a dir: renuncies a un estalvi petit de self-refresh i a canvi la màquina reprèn, i no es bloqueja mentre l’estàs mirant. Si vols recuperar aquest watt, treu-lo de la ruta de repòs amb un framebuffer en negre — a OLED, negre vol dir píxels apagats — i no reactivant el PSR que encalla el PHY. I deixa l’apagada de panell per DPMS fora d’això: mou el mateix PHY.

Problemes coneguts no crítics

NVIDIA “PRH failed to update thermal limit”

NVRM: GPU0 nvAssertFailedNoLog: Assertion failed: PRH failed to update thermal limit!

Surt dues vegades per arrencada al meu sistema. És un bug d’nvidia-open — el Platform Request Handler no aconsegueix sincronitzar amb el firmware GSP. No és fatal, no provoca penjades, no afecta la suspensió. Canvia al paquet propietari nvidia si et molesta; si no, ignora’l.

“Correcting number of heads (0x00)” — esperat quan no hi ha cap pantalla externa connectada. No és la teva configuració.

Deprecació de vm.laptop_mode a TLP — cosmètic. Treu la línia de la teva config de TLP.

El que vaig fer malament (i val la pena llegir-ho)

Durant mesos vaig estar convençut que el culpable era el selective fetch de PSR2. Vaig posar i915.enable_psr2_sel_fetch=0, vaig deixar enable_psr=2 i vaig citar linux-surface #2158 com a suport. Canviava el moment de la fallada, així que me’l vaig creure. Era irrellevant: el panell va en PSR1, així que sel_fetch no va ser mai a la ruta. Les penjades van continuar. El que les va acabar va ser apagar el PSR sencer.

Un paràmetre que desplaça els símptomes no és un paràmetre que arregli la causa. Verifica contra un sistema que saps que funciona, en comptes de raonar cap endavant des d’un mecanisme plausible, que és el que vaig fer durant un any.

Dos més, en la mateixa línia:

  • No afegeixis mai cap paràmetre d’arrencada i8042.*. Amb la teoria del teclat vaig provar i8042.reset i8042.nopnp. S’executen dins de la ruta de represa d’s2idle i pengen la màquina sencera — estrictament pitjor que la fallada original. No va ser mai el teclat; el teclat era aigües avall del modeset lock.
  • No posis mei / mei_me a la llista negra. S’enllaça a i915 com a mei_gsc_proxy, cosa que el situa aigües avall de la GPU, no com a causa. Posar-lo a la llista negra va moure la fallada de lloc i no va arreglar res.

Un any i més de 300 apagades forçades per una sola línia, i la línia ni tan sols va ser la que vaig publicar primer. Així són les coses de vegades.

Si això no ho arregla

enable_psr=0 acaba amb la classe de penjada del PSR. No acaba amb totes les fallades de represa d’aquesta plataforma, i jo encara en persegueixo una.

Compara els teus logs abans que els teus símptomes. Si la penjada en reprendre ve amb els errors de PHY A i flip_done de dalt, ets a la fallada de què tracta aquest article. Si el que se’t mor és l’escriptori i tots els dispositius d’entrada alhora mentre el kernel continua funcionant amb normalitat — SSH respon, el disc sincronitza — i dmesg no mostra ni un sol *ERROR* de cap driver, això és una altra cosa completament diferent. El meu va resultar estar a la capa de sessió. En tots els cicles fallits que vaig capturar, logind no va posar en pausa el dispositiu DRM de la iGPU en suspendre, i en reprendre li va enviar igualment l’ordre de reprendre. Xorg no va reaccionar a aquesta ordre i va continuar fent modeset sense ser DRM master, cosa que falla. El kernel no és la variable: el kernel LTS 6.18 falla exactament igual que el 7.2. Està obert amunt a systemd#43352, i no està arreglat.

Per a aquest tampoc no cal el botó d’engegada. Alt+PetSis+k (SAK) mata tot el que penja de la consola activa, és a dir, la sessió de X congelada i res més. Amb el meu autologin, la sessió nova era a punt en un segon; amb un gestor de pantalla hauries de tornar a la seva pantalla de login. Els serveis del sistema continuen funcionant. logind també mor, perquè té la consola oberta, però es reinicia sol en un segon. Les finestres obertes es perden, perquè moren amb X. Si vols, prova abans v uns segons; no costa res, però a mi no em va tornar la sessió.

Un dmesg net és evidència, no silenci. Vaig trigar una quantitat vergonyosa de temps a tractar-lo com a tal.

Referències

Etiquetes

#linux #meteor-lake #thinkpad #suspend #kernel #i915

Compartir article

AS

Angel Sulev

Cybersecurity + Agentic AI Expert

Especialista sènior en ciberseguretat i IA Agèntica amb 30+ anys transformant la seguretat en avantatge competitiu.

Més sobre mi

Articles Relacionats