Cuando el portátil se duerme y no vuelve

1. El problema

Al suspender el equipo, la pantalla se apagaba pero era imposible reanudarlo: teclado, touchpad y botón de encendido dejaban de responder. La única salida era forzar el apagado manteniendo presionado el botón de encendido y reiniciar desde cero. El síntoma se reproducía exactamente igual en Fedora y en Debian.

2. Inventario inicial de energía y drivers

La investigación comenzó recopilando información del sistema sin aplicar modificaciones previas. Estos comandos determinan el tipo de suspensión que la BIOS ofrece al kernel y el estado del controlador NVIDIA:

cat /sys/power/mem_sleep
sudo dmidecode -s bios-version
nvidia-smi
cat /proc/driver/nvidia/params | grep -i S0ix

En este portátil, /sys/power/mem_sleep devolvió únicamente [s2idle]. No existe soporte de suspensión tradicional S3 (deep), por lo que forzar parámetros de kernel como mem_sleep_default=deep no constituye una solución válida.

El controlador NVIDIA estaba correctamente cargado y la GPU anunciaba soporte para autorrefresco de memoria de video (VRAM):

grep -H 'Video Memory Self Refresh' /proc/driver/nvidia/gpus/*/power
# Resultado:
# Video Memory Self Refresh: Supported

Sin embargo, la gestión de S0ix en el driver propietario venía desactivada por defecto:

grep -E 'EnableS0ixPowerManagement|UseKernelSuspendNotifiers|PreserveVideoMemoryAllocations' \
  /proc/driver/nvidia/params

# EnableS0ixPowerManagement: 0

Al revisar el registro de sistema (journalctl -b -1) tras un cuelgue, la traza terminaba abruptamente en PM: suspend entry (s2idle), sin registrar ninguna línea de retorno o reanudación.

3. Prueba controlada de S0ix en NVIDIA

Dado que tanto la plataforma como la GPU declaraban soporte teórico, se probó habilitar el parámetro recomendado por la documentación de NVIDIA. El cambio se implementó de forma aislada y completamente reversible:

printf '%s\n' 'options nvidia NVreg_EnableS0ixPowerManagement=1' \
  | sudo tee /etc/modprobe.d/nvidia-s0ix.conf
sudo dracut --force
systemctl reboot

Tras reiniciar, se comprobó que el parámetro estuviera activo:

grep EnableS0ixPowerManagement /proc/driver/nvidia/params
# EnableS0ixPowerManagement: 1

Reversión del experimento

Para no arrastrar configuraciones no concluyentes, se retiró el archivo de inmediato:

sudo rm /etc/modprobe.d/nvidia-s0ix.conf
sudo dracut --force
systemctl reboot

4. Aislamiento de fases con pm_test

La interfaz /sys/power/pm_test del kernel Linux permite simular etapas específicas del ciclo de energía y forzar un retorno automático tras aproximadamente cinco segundos. Esto permite discernir si la falla ocurre en los procesos de usuario, en los drivers de dispositivos o en el firmware ACPI.

echo devices | sudo tee /sys/power/pm_test
systemctl suspend
echo none | sudo tee /sys/power/pm_test

echo platform | sudo tee /sys/power/pm_test
systemctl suspend

Esta diferenciación localizó el problema directamente en la interacción entre la BIOS/ACPI y el hardware. Adicionalmente, el log de kernel revelaba advertencias ACPI vinculadas a la GPU dedicada (por ejemplo, llamadas a símbolos no resueltos en PEGP.GPS).

5. Prueba de hibernación: guardado correcto, apagado incompleto

Como alternativa para preservar el estado de trabajo se configuró hibernación mediante un archivo swap de 20 GB dentro de la partición ext4 de Fedora, sin alterar particiones ni tocar las instalaciones de Windows o Debian.

Creación del archivo swap

sudo fallocate -l 20G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Cálculo del desplazamiento físico (resume_offset)

sudo filefrag -v /swapfile
# El primer número bajo la columna 'physical_offset' corresponde al resume_offset.

Persistencia y configuración del kernel

echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

sudo mkdir -p /etc/systemd/sleep.conf.d
printf '[Sleep]\nHibernateMode=shutdown\n' \
  | sudo tee /etc/systemd/sleep.conf.d/hibernate.conf

sudo grubby --update-kernel=ALL \
  --args="resume=UUID=<UUID_FEDORA> resume_offset=<OFFSET_SWAPFILE>"
sudo dracut --force
systemctl reboot

6. Reversión completa y bloqueo preventivo

Para recuperar el espacio en disco y asegurar que el portátil nunca intente suspenderse o hibernar de forma accidental (por ejemplo, al cerrar la tapa), se retiró el swapfile y se enmascararon los objetivos de energía en systemd:

sudo swapoff /swapfile
sudo sed -i '\|^/swapfile[[:space:]]|d' /etc/fstab
sudo rm /swapfile
sudo rm -f /etc/systemd/sleep.conf.d/hibernate.conf

sudo grubby --update-kernel=ALL \
  --remove-args="resume=UUID=<UUID_FEDORA> resume_offset=<OFFSET_SWAPFILE>"
sudo dracut --force

# Enmascarar objetivos de suspensión e hibernación
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemctl reboot

Tras reiniciar, se verificó que los cuatro objetivos apuntaran a /dev/null, manteniéndose únicamente zram para el manejo normal de memoria.

Cómo desenmascarar si una futura BIOS lo soluciona

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

Estrategia de uso estable recomendada

• Suspensiones bloqueadas: Mantener enmascarados los targets de systemd.
• Apagado de pantalla: Permitir que la pantalla se apague por inactividad (DPMS funciona sin colgar el equipo).
• Transporte y pausas largas: Realizar apagado normal del sistema.
• Restauración de sesión: Usar la opción de recordar aplicaciones abiertas de KDE Plasma.
• Actualizaciones: Esperar revisiones de BIOS posteriores a PQCN27WW de Lenovo.

Referencias y documentación recomendada: Depuración básica de energía en el Kernel Linux ↗, Guía de Power Management de NVIDIA ↗ y Página oficial de soporte Lenovo LOQ 15ARP9 ↗.