Cómo se resolvió el problema de suspensión y reactivación de Linux en GPUs AMD

• Aparición del problema: En una desktop con arranque dual de Windows y Linux, ocurría un fallo al entrar en modo de suspensión en Linux cuando se usaba una gran cantidad de RAM. Al reactivar el sistema, aparecía una pantalla negra o quedaba sin respuesta. Este problema se debía a un bug de administración de energía/memoria en el driver amdgpu.

• Diagnóstico del problema: Se estaba ejecutando Arch Linux en un sistema con motherboard Gigabyte B550M DS3H y GPU AMD RX 570. Tras los fallos del sistema, se revisaron los logs con journalctl y se descubrió un error de falta de memoria (OOM) en amdgpu_device_suspend. El driver NVMe no lograba inicializarse al reanudar el sistema, por lo que este se congelaba y no se registraban logs.

• Intentos de solución: Se modificó la configuración de systemd para probar varios modos de suspensión y se desactivó la suspensión asíncrona para simplificar el problema, pero no se resolvió la causa de fondo. También se confirmó que el fallo ocurría durante el proceso de eliminación de buffers TTM de amdgpu.

• Causa del problema: Cuando el sistema entra en modo de suspensión S3, se corta la energía de la GPU PCIe y se pierden los datos en la VRAM. Para evitarlo, el driver de la GPU debe respaldar la VRAM en la RAM del sistema, pero el driver amdgpu de Linux provocaba una falla por falta de memoria si no había RAM suficiente.

• Solución: Mario Limonciello escribió un parche del kernel para respaldar la VRAM antes de que se detenga el almacenamiento basado en disco. Este parche cambia el respaldo de VRAM de la etapa dpm_suspend() a dpm_prepare(), de modo que la suspensión pueda abortarse si falta memoria.

• Resolución de problemas adicional: El usuario escribió un script para respaldar la VRAM desde espacio de usuario, moviéndola a la RAM del sistema antes de la suspensión. Sin embargo, si había varias apps 3D ejecutándose, la VRAM podía seguir moviéndose hacia la GPU y provocar fallos.

• Solución final: Se cambió el proceso para respaldar la VRAM en la etapa PM_SUSPEND_PREPARE usando la API de notificación de administración de energía. Gracias a esto, la VRAM puede moverse a la RAM del sistema antes de que se desactive el swap, resolviendo el problema.

• Conclusión: Este problema se resolvió gracias al esfuerzo de varias personas y múltiples intentos, y está previsto que se incluya en Linux kernel 6.14.

[GN⁺]

Opiniones de Hacker News

• Hay dudas sobre la suposición de que, cuando una desktop entra en modo de suspensión S3, el sistema corta la energía de la GPU PCIe

  • S3 debería cortar la energía de todo excepto la RAM, pero las motherboards Gigabyte Aorus tienen un problema por un bug de suspensión del SSD NVMe que impide suspender o reanudar correctamente
  • Para resolverlo, hay que agregar una regla de udev
  • También hay una forma de evitar el despertar desde ciertos puertos PCIe
  • Hay una manera de encontrar los dispositivos PCIe problemáticos que activan el despertar
  • Se puede usar el comando udevadm para obtener información del dispositivo
  • También se puede resolver el problema usando un script de shell

• El autor de memreserver comparte su experiencia depurando problemas de suspensión en Linux

  • Señala que Linux no podía ejecutar un gancho de interrupción confiable antes de que se congelaran los subsistemas de disco y memoria
  • Es difícil encontrar información relacionada en Freedesktop Gitlab

• Se explica por qué es difícil implementar la función de suspensión en Linux y lo complicado que resulta depurarla

  • Está teniendo un problema en una ThinkPad P1G4 donde el ventilador no se apaga automáticamente
  • También ha experimentado audio distorsionado en audífonos Bluetooth después de suspender

• Un usuario de una ThinkPad basada en Ryzen comenta que está teniendo problemas de suspensión en Linux y espera con interés la versión 6.14

• Se comparte la opinión de que el problema de "suspensión/despertar" es un problema NP-completo

• Se plantea que esto podría ayudar a quienes usan una laptop Framework AMD con expansión de GPU y dual boot Linux/Windows

  • Expresa su intención de hacer una donación

• Un usuario que está sufriendo un problema en el que la PC casi se congela después de suspender con una GPU AMD sigue intentando resolverlo

  • El problema apareció después de cambiar de una RX 5700 XT a una RX 7900 XTX
  • Espera que la versión 6.14 pueda solucionar el problema

• Se comparte la opinión de que siempre ha tenido problemas con la suspensión mientras usa Linux

  • Incluso usando hardware de Intel, AMD, ATI y NVIDIA, muchas veces la suspensión o la hibernación no funcionan correctamente

• Se comparte una experiencia depurando problemas de suspensión en hardware IoT

  • En Linux, la hibernación del sistema es más confiable que la suspensión
  • Si el SSD es rápido, conviene usar la hibernación del sistema

• Se explica que la gestión de memoria y las condiciones de OOM siguen siendo problemas difíciles en Linux

  • Agregar más RAM para resolver problemas de OOM es ineficiente
  • Se comparte la opinión de que la función de shell de depuración de systemd es útil
  • Hay charlas útiles sobre subsistemas del kernel de Linux disponibles en línea