Cómo se rastreó y corrigió el bloqueo de suspensión y reanudación en Linux que ocurre con GPU AMD

 (nyanpasu64.gitlab.io)
1 puntos por GN⁺ 2025-02-18 | 1 comentarios | Compartir por WhatsApp
  • En un escritorio Linux basado en AMD RX 570, al suspender con alto uso de RAM, tras reanudar se repetían una pantalla negra o un estado sin respuesta a la entrada, por lo que hubo que rastrear no solo un problema de pantalla sino también todo el flujo de administración de energía del kernel
  • La causa principal estaba en que amdgpu, que debe respaldar la VRAM en la RAM del sistema antes de la suspensión S3, no lograba usar correctamente el swap en disco cuando faltaba RAM libre y terminaba colapsando por OOM
  • Un primer parche que adelantaba la expulsión de VRAM de dpm_suspend() a dpm_prepare() redujo la competencia con el apagado de energía del SSD, pero pm_restrict_gfp_mask() ya había desactivado el swap, así que la falta de memoria contigua podía seguir ocurriendo
  • Después, al cambiarlo para llamar a amdgpu_device_evict_resources() en el momento de PM_SUSPEND_PREPARE mediante register_pm_notifier(), fue posible respaldar la VRAM mientras el swap y el disco seguían activos, y en el entorno de prueba la suspensión funcionó incluso con alto uso de RAM y VRAM
  • Este cambio se integró en el árbol de amdgpu, pero se revirtió en 2025-06 por una posible condición de deadlock; en rutas de suspensión que no congelan primero los procesos de usuario, las apps 3D pueden volver a traer la VRAM al GPU y bloquear la expulsión

Fallos repetidos de suspensión y diagnóstico inicial equivocado

  • El escritorio estaba configurado con dual boot entre Windows y Linux, y al intentar suspender en Linux con alto uso de RAM, el sistema se rompía con frecuencia
    • Tras reanudar, a veces solo aparecía una pantalla negra con el cursor moviéndose, o no había salida de video y solo respondía a magic SysRq o a un reinicio forzado
    • En algunos casos el reloj de la pantalla de bloqueo de KDE se actualizaba en tiempo real, pero al iniciar sesión o interactuar el sistema se congelaba
  • El entorno de prueba era Gigabyte B550M DS3H, GPU AMD RX 570, SSD NVMe Kingston A2000 1TB, Arch Linux, systemd-boot y Linux 6.4
  • Al revisar los logs del arranque anterior con journalctl --system -b -1, en algunos intentos de suspensión aparecía un error de OOM dentro del código del kernel bajo amdgpu_device_suspend
  • Muchos casos de falla terminaban con los siguientes logs, sin quedar registro de que el sistema roto hubiera vuelto a despertar
    • systemd-sleep: Entering sleep state 'suspend'...
    • kernel: PM: suspend entry (deep)
  • Al principio se sospechó del modo de ahorro de energía APST del NVMe, por lo que se probaron nvme_core.default_ps_max_latency_us=0, iommu=soft, una actualización del firmware del SSD y el reemplazo del SSD de arranque de 2TB, pero el problema no se resolvió

Herramientas de depuración que acotaron dónde fallaba

  • Como systemd podía intentar varios modos de suspensión en secuencia, generando ruido en los logs y empeorando el estado del kernel, se agregó SuspendState=mem en /etc/systemd/sleep.conf
    • La depuración se volvió más simple, pero la causa de fondo seguía ahí
  • Se rastreó el punto de falla con echo 1 > /sys/power/pm_trace
    • pm_trace guarda el estado de avance de suspensión y reanudación en el reloj del sistema
    • Gracias al efecto secundario de desactivar la suspensión asíncrona, también se observó que tras fallar la suspensión de amdgpu el sistema se recuperaba en vez de quedar completamente colgado
  • Se agregó el parámetro de kernel systemd.debug_shell para poder abrir un shell root en Ctrl-Alt-F9 incluso sin iniciar sesión en KDE o en una TTY
  • Como a veces se rompían el controlador USB y el teclado, se usó un teclado PS/2, y después se configuró una consola serial
    • Parámetros del kernel: no_console_suspend console=tty0 console=ttyS0,115200 loglevel=8
    • Desde una laptop se capturaban los logs continuamente con sudo minicom --device /dev/ttyUSB0 --baudrate 115200
    • La consola serial permitió ejecutar comandos y recolectar logs incluso después de que se rompieran la pantalla y la red, aunque con limitaciones de velocidad de transmisión y manejo de color y tamaño de pantalla

La relación entre la expulsión de VRAM de amdgpu y el OOM

  • Los logs de crash apuntaban en general a la ruta de expulsión de buffers TTM de amdgpu
    • amdgpu_device_evict_resources()
    • amdgpu_ttm_evict_resources()
  • En reportes de bugs relacionados se confirmó que “evict” se refería a copiar la VRAM a la RAM del sistema o mover RAM del sistema al swap
  • Cuando el escritorio entra en suspensión S3, se corta la energía de la GPU PCIe y los datos de los chips de VRAM se pierden
    • El driver de la GPU debe copiar a la RAM del sistema la VRAM en uso antes de suspender
    • Tras reanudar, debe restaurar de nuevo esos datos desde la RAM
  • El driver amdgpu de Linux tenía un problema: cuando no había suficiente RAM libre para alojar toda la VRAM en uso, en vez de mover RAM del sistema al swap en disco, fallaba por falta de memoria
  • Si Linux encuentra OOM durante la suspensión, intenta cancelar la suspensión y volver a arrancar los dispositivos, pero como la suspensión ya quedó interrumpida, algunos drivers pueden romperse o volver a provocar OOM durante suspend/resume
    • El riesgo es mayor cuando la suspensión asíncrona está activada
    • También puede ocurrir que la suspensión sí se complete, pero aparezca un OOM durante el arranque de dispositivos en la reanudación

Primer intento de solución: adelantar el momento del respaldo de VRAM

  • Mario Limonciello sugirió activar /sys/power/pm_print_times y /sys/power/pm_debug_messages y revisar los logs de suspensión
  • Los logs mostraban que los drivers de NVMe y amdgpu entraban en pci_pm_suspend en paralelo durante la suspensión
  • Al principio se buscó una forma de hacer que la suspensión de la GPU ocurriera antes que la del SSD, y también se revisó el mecanismo de ordenamiento de suspensión de dispositivos de Linux
    • Ese mecanismo parecía más orientado a sincronizar periféricos estrechamente conectados que a suspender todas las GPU antes que todos los discos del sistema
  • Mario propuso expulsar la VRAM en la etapa prepare de la suspensión de Linux y escribió un parche del kernel que movía la expulsión de VRAM de dpm_suspend() a dpm_prepare()
  • El flujo antes y después del cambio era el siguiente
    • Antes: el respaldo de VRAM se ejecutaba en dpm_suspend(), por lo que podía superponerse con el apagado del SSD
    • Después: en dpm_prepare() primero se intentaba respaldar la VRAM y, si fallaba, la suspensión se cancelaba antes de suspender otros dispositivos
  • Este cambio fue mejor que el anterior, pero seguía fallando con alto uso de RAM porque pm_restrict_gfp_mask() desactiva el swap antes de dpm_prepare()
    • amdgpu_ttm_evict_resources() podía fallar por falta de memoria contigua
    • Incluso si toda la VRAM lograba entrar en RAM, si después no quedaba espacio suficiente para asignaciones del driver, podía ocurrir OOM durante la suspensión o el despertar

Un crash distinto de amdgpu encontrado con Ghidra

  • Durante las pruebas apareció el error BUG: unable to handle page fault for address: fffffffffffffffc, que parecía una desreferencia de puntero casi nulo
  • El log del crash apuntaba a dm_resume+0x200, pero no daba el número de línea del código fuente
  • Después de guardar y extraer el módulo del kernel amdgpu.ko, se decompiló con Ghidra para mapear la ubicación del crash dentro de dm_resume a líneas del código fuente del kernel
  • El problema aparecía en el macro for_each_new_crtc_in_state(dm->cached_state, crtc, new_crtc_state, i)
    • dm->cached_state no era un puntero válido sino fffffffffffffff4
    • Después, al leer el campo [RSI + 0x8], se producía un page fault en la dirección fffffffffffffffc
  • La causa estaba en que dm_suspend() guardaba directamente en un puntero el valor de retorno de drm_atomic_helper_suspend()
    • drm_atomic_helper_suspend() puede devolver un puntero válido o ERR_PTR(err)
    • Por OOM devolvía -ENOMEM (-12), y se concluyó que el código de suspensión de amdgpu lo estaba desreferenciando como si fuera un puntero
  • Mario corrigió este problema agregando código para comprobar el valor de retorno fallido y abortar la suspensión

Camino descartado: permitir swap durante prepare()

  • La razón por la que la suspensión seguía fallando con alto uso de RAM era que amdgpu respaldaba la VRAM en dpm_prepare(), pero para ese momento pm_restrict_gfp_mask() ya había desactivado el swap en disco
  • Un intento fue permitir swap durante dpm_prepare() y desactivarlo recién justo antes de que dpm_suspend() apagara los discos
  • Para eso se experimentó moviendo la llamada a pm_restrict_gfp_mask() desde enter_state() hacia más adentro, dentro de dpm_suspend_start()
  • Había fuertes limitaciones prácticas
    • pm_restrict_gfp_mask() está declarada en kernel/power/power.h y se llama desde kernel/power/suspend.c
    • El lugar desde donde se quería llamar era drivers/base/power/main.c, y ese archivo normalmente no incluye headers de kernel/power/
    • Como hack temporal se agregó #include <../kernel/power/power.h>, pero para upstream habría que justificar esa estructura
  • También había problemas de exactitud con la suspensión híbrida
    • La suspensión híbrida guarda la imagen del sistema, llama a pm_restrict_gfp_mask() y luego invoca suspend_devices_and_enter() con el swap ya desactivado
    • Si se llamaba otra vez a la misma función aparecía una advertencia y pm_restore_gfp_mask() podía no volver a activar el swap
  • En las pruebas bajó la frecuencia de fallas o crashes, pero no se resolvió por completo, y como era un cambio frágil que tocaba la administración central de energía, no se intentó upstream

Solución temporal en espacio de usuario: amdgpu-sleep

  • En 2024-10, tras cerrar SuperTuxKart, al suspender y luego reanudar volvió a aparecer una pantalla negra
    • Según los logs, el primer intento de suspensión dio OOM en dpm_prepare(), y el siguiente terminó en un crash por asignación de memoria en bw_calcs() de amdgpu durante la reanudación
  • Se tomó como referencia el mecanismo de respaldo de VRAM en espacio de usuario de NVIDIA
    • NVIDIA hace el respaldo y restauración de VRAM escribiendo en /proc/driver/nvidia/suspend desde servicios que systemd ejecuta antes y después de invocar la suspensión del kernel
  • Con base en eso se creó el paquete amdgpu-sleep para Arch Linux
    • Antes de suspender, lee /sys/kernel/debug/dri/1/amdgpu_evict_vram
    • Ese endpoint de debug le indica a amdgpu que guarde toda la VRAM en la RAM del sistema
    • systemd espera a que termine la expulsión de la VRAM de la GPU y solo después inicia la suspensión del kernel
  • Al suspender el escritorio, esto lograba copiar rápidamente la VRAM a memoria y, si hacía falta, empujar RAM al swap para completar con éxito
  • Cuando había varias apps 3D ejecutándose, seguían renderizando frames y volvían a traer la VRAM a la GPU, provocando un livelock de tira y afloja con amdgpu_evict_vram
    • Ese estado duraba más de 70 segundos antes de que amdgpu_evict_vram se rindiera
    • Después systemd iniciaba la suspensión del kernel y, al congelar userspace, la expulsión de VRAM sí tenía éxito en la etapa del kernel
  • Este script se siguió usando porque la frecuencia del livelock no era menor que la frecuencia de crashes a nivel kernel cuando el script estaba desactivado

Parche final: notifier de power management

  • En 2024-11, Mario pidió probar un parche que permitía la expulsión mientras el swap seguía activo
  • El parche estaba estructurado alrededor de una llamada a register_pm_notifier() y usaba la API de power management notifier de Linux
  • El callback recibía los mensajes PM_HIBERNATION_PREPARE y PM_SUSPEND_PREPARE y llamaba a amdgpu_device_evict_resources()
  • PM_SUSPEND_PREPARE se emite en enter_state() → suspend_prepare() mediante pm_notifier_call_chain_robust(PM_SUSPEND_PREPARE, PM_POST_SUSPEND)
    • A los drivers con callback notifier se les entrega PM_SUSPEND_PREPARE
    • Si ocurre una falla, a los drivers ya preparados se les envía PM_POST_SUSPEND y la suspensión se aborta
  • Si la VRAM se expulsaba en este punto, todavía no se había ejecutado pm_restrict_gfp_mask(), así que el swap seguía activo y los discos aún no estaban congelados
  • El flujo modificado quedaba así
    • suspend_prepare()
    • PM_SUSPEND_PREPARE
    • amdgpu_device_pm_notifier() → amdgpu_device_evict_resources()
    • pm_restrict_gfp_mask()
    • dpm_prepare()
    • dpm_suspend()
  • Tras compilar un kernel personalizado con el driver amdgpu modificado y probarlo, no aparecieron errores en múltiples suspensiones incluso con alto uso de RAM y VRAM
  • Aun así, apareció un efecto secundario: como amdgpu respaldaba la VRAM antes de que PipeWire o el kernel silenciaran los parlantes, el audio se repetía durante algunos segundos
  • Después de varias rondas de revisión, este cambio se integró en el árbol de amdgpu y llevó, tras más de un año de intentos, a una etapa en la que ese bug quedaba resuelto

Actualización de 2025-06 y reversión

  • Al principio se esperaba que el cambio entrara en el kernel Linux estable 6.14, pero luego se revirtió por un posible deadlock
  • El nuevo problema aparece cuando systemd llama a la suspensión del sistema sin congelar primero todos los procesos de espacio de usuario
    • El kernel intenta expulsar la VRAM a la RAM del sistema antes de congelar por su cuenta los procesos
    • Al mismo tiempo, si un programa 3D vuelve a traer la VRAM a la GPU, el proceso de expulsión durante la suspensión puede entrar en deadlock
  • Esto es similar al livelock que se observó con la solución temporal en espacio de usuario amdgpu_evict_vram
  • El maintainer de Linux PM propuso mover la llamada a pm_restrict_gfp_mask() hacia dentro de suspend_devices_and_enter()
    • Esto conecta con la dirección ya probada antes de permitir swap durante prepare()
  • No hay planes de implementarlo y enviarlo directamente
    • La GPU AMD se movió a una computadora vieja con CPU más lento y 8GB de memoria, y en ese entorno no se quiere compilar el kernel
  • La computadora principal se actualizó a una Intel Arc B570, pero el mismo tipo de problema sigue ocurriendo incluso con 10GB de VRAM
    • Ese problema fue reportado en el bug tracker del kernel drm/xe

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-02-18
Opiniones de Hacker News

  • No está claro que, cuando una desktop entra en suspensión S3, se corte la energía de la GPU PCIe
    Es cierto que S3 corta toda la energía excepto la de la RAM, pero, por ejemplo, las motherboards Gigabyte Aorus son tristemente célebres por un bug de suspensión de los SSD NVMe que impide que el sistema se duerma o despierte correctamente
    Por lo general se puede evitar con una regla de udev que bloquee el despertar en todos los puertos PCIe: ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
    De forma más acotada, también se puede especificar solo el puerto PCIe problemático con algo como ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc", y se puede encontrar la causa con /proc/acpi/wakeup, /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID, udevadm info --attribute-walk /dev/whatever
    En lugar de udev, también se puede alternar /proc/acpi/wakeup desde un servicio de systemd o un script de automatización, pero es menos confiable; estos problemas de suspensión en Linux son realmente agotadores

    • En mi motherboard tuve que poner ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled" en /etc/udev/rules.d/ para impedir los despertares espontáneos
      El receptor Logitech Bolt también despierta de inmediato varias computadoras con Linux, pero no sé por qué no pasa en Windows; tampoco me queda claro si para intentar una captura USB haría falta equipo como un analizador lógico o Glasgow
      Por ahora agregué la regla ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled" para bloquearlo
    • Creo que desperdicié varios kWh por este problema en una motherboard Aorus, así que esperaba una solución, pero en mi caso no funcionó
    • También tenía problemas de suspensión en una X570 Aorus Master, y se solucionó ejecutando echo GPP0 >> /proc/acpi/wakeup desde una unidad de systemd al arrancar
      Sin embargo, la primera suspensión después de arrancar siempre despertaba de inmediato; al aplicar la regla de udev de arriba, parece que ese problema también se resolvió
    • Uno termina esperando que sea posible detectar si el hardware realmente entró en suspensión, o que volver a despertar hardware que no llegó a dormirse no cause problemas
      Debería ser posible enviar una orden de suspensión a un dispositivo PCIe, luego dormir el bus en sí, y al despertar reactivar primero el bus y después el dispositivo
    • Sufrí bastante con este problema, pero este método tampoco me funcionó; lo que recopilé está en https://bbs.archlinux.org/viewtopic.php?id=302440
      En mi caso, la causa del despertar parece venir de .../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6, pero no entiendo bien qué significa esa ruta

  • Como autor de memreserver, una de las soluciones alternativas en espacio de usuario mencionadas, depuré este problema hace algunos años
    El comentario público que pude encontrar rápido está en https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17..., y recuerdo que también hubo una discusión en una lista de correo
    El punto central era que Linux no tenía hooks de suspensión por etapas que se ejecutaran de forma confiable antes de que se congelaran el disco y partes del subsistema de memoria, y ahora parece que eso ya es posible
    Lamentablemente, Freedesktop Gitlab parece no indexarse bien, así que este conocimiento quedó enterrado

  • Un trabajo realmente excelente.
    Si alguna vez te preguntaste por qué en Linux es tan difícil hacer que la transición a suspensión funcione bien y también depurarla, este artículo por sí solo muestra cuántos puntos pueden romperse.
    Incluso ahora, en una ThinkPad P1G4, si no apago manualmente el ventilador antes de suspender, no se apaga solo; y recientemente, después de reanudar desde suspensión, empezó a aparecer ruido en unos audífonos Bluetooth, así que también tuve que desactivar la suspensión de nodos de PipeWire: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...

    • Sorprende que, incluso en 2025, el sleep/suspend en laptops Linux todavía no funcione bien.
      La primera vez que tuve este tipo de problema fue probablemente hace unos 15 años.
    • La suspensión es realmente cuestión de suerte, y errores como los del artículo son muy difíciles de depurar.
      Entre las soluciones alternativas que se proponen para varios problemas hay algunas que desactivan modos de ahorro de energía, pero como el objetivo de usar suspensión suele ser aumentar la duración de la batería, ese enfoque no es muy realista porque puede reducir mucho el tiempo de uso real.
      Aun así, no es imposible hacer funcionar la suspensión S0ix.
      Instalé Arch Linux en dispositivos portátiles basados en AMD 7840U y AMD 8840U, es decir, GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3 y OneXPlayer X1 Ryzen, y parece poco probable que esas compañías los hayan diseñado o probado pensando en soporte para Linux.
      Sin embargo, con apenas unos ajustes en fuentes de activación falsas en /proc/acpi/wakeup y /sys/devices/*/*/*/power/wakeup, obtuve soporte S0ix casi perfecto, salvo en la OneXPlayer X1 Ryzen más reciente.
      El soporte del kernel Linux base también es excelente: la pantalla táctil, la entrada con lápiz, Wi-Fi y Bluetooth funcionan bien, y la única carencia que vi es el soporte del lector de huellas.
      Estos fabricantes pequeños suelen hacer menos personalización extrema de componentes y menos integración minuciosa, algo que en la práctica se nota en que los dispositivos son unos milímetros más gruesos.
      Por eso tienden a elegir componentes más conservadores y, como resultado, el soporte para Linux puede terminar siendo sorprendentemente bueno.
    • Para que un usuario final pueda usar bien la suspensión sin complicarse, la respuesta es comprar hardware con compatibilidad verificada.
      En mi experiencia, en ThinkPad empresariales ha sido muy estable desde hace mucho tiempo, y los usuarios de Windows del mismo modelo parecen tener problemas de suspensión con más frecuencia.

  • Personalmente, lo agradezco muchísimo.
    Mi laptop principal es una ThinkPad basada en Ryzen que corre Linux, y uso con frecuencia la suspensión y la hibernación; he venido sufriendo este problema de forma intermitente.
    Espero con ganas Linux 6.14.

  • La razón por la que dm->cached_state guardó -12 en vez de un puntero probablemente sea que, durante suspend, dm_suspend() asignó directamente dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev)).
    La función llamada, drm_atomic_helper_suspend(), puede devolver un puntero válido o un ERR_PTR(err) que codifica un error como puntero negativo, y el llamador no verificó el error, lo metió directamente en el puntero y luego lo desreferenció al hacer resume.
    Otra razón más para incorporar Rust al kernel; si se obligara a manejar el tipo Result, sería difícil que ocurrieran cosas así.

    • También se pueden crear tipos suma algebraicos con el preprocesador de C: https://github.com/Hirrolot/datatype99
      Pero los valores por defecto importan, y el historial del kernel de posponer durante mucho tiempo la modernización de sus prácticas de codificación juega en contra de las mejoras del lado de C.
      Irónicamente, esa misma resistencia también frustra a los desarrolladores de Rust, porque ni siquiera se recibe bien limpiar cada subsistema o documentar cómo se comporta.
      Si algo como https://github.com/llvm/llvm-project/issues/74205 llegara hasta el kernel, podría ayudar, pero aun así parece que seguirían eligiendo sobrecargar punteros manualmente en vez de asegurar la seguridad mediante tipos.

  • Uso arranque dual Linux/Windows en una laptop Framework AMD con el módulo de expansión de GPU, así que este trabajo parece que me va a ayudar.
    Me gustaría apoyarlo directamente o donar a la organización benéfica que prefiera; la información de contacto está en mi perfil.

  • Pensaba que los dos grandes problemas de la informática eran nombrar cosas, invalidar cachés y los errores off-by-one, pero después de conocer los problemas de sleep/wake, esto parece NP-completo.

    • Veo sleep/wake como un subconjunto de la invalidación de caché.
      Si todos los periféricos no tuvieran estado, probablemente no sería un problema.
    • Solo en Linux; en Windows es O(n²), y en macOS es O(log n).

  • En Linux, la gestión de memoria y, en especial, las situaciones de OOM siguen siendo una pesadilla increíblemente dolorosa
    No es que me pase siempre, pero definitivamente he intentado depurar problemas parecidos y he fracasado; al final, cuando aparece un OOM, normalmente termino poniendo más RAM
    Es un desperdicio y es caro, pero manejar con elegancia las situaciones de OOM parece que seguirá siendo un problema difícil de resolver para Linux
    Este trabajo es excelente y servirá como punto de referencia para depurar problemas similares en el futuro
    También me alegra la función debug-shell de systemd; no sabía que existía algo así
    Aunque mi placa X670E Steel Legend parece no tener header serial, así que me da curiosidad cómo funcionan hoy en día los puertos seriales integrados
    ¿Estarán conectados a las líneas PCIe del chipset?
    Al meterse en el kernel de Linux, ayudan mucho las grabaciones de charlas sobre subsistemas del kernel en eventos como FOSDEM o Linux Plumbers Conference; por ejemplo, este es el video del subsistema de memoria TTM que usan la mayoría de los drivers DRM de GPU de escritorio: https://www.youtube.com/watch?v=MG7_tUNKSt0

    • En Windows, el puerto serial de mi motherboard aparece conectado a Pci Bus → PCI standard ISA bridge
      Viva DOS
      Veré el video de TTM cuando tenga tiempo
    • Encerrar el OOM con cgroups funcionó bastante bien
      No sé bien si existe una forma moderna de manejar OOM mejor que lo que hace Linux, y me gustaría conocer material para leer al respecto si lo hay
    • Exacto, incluso diciéndolo con buena onda, es horrible
      Linux no maneja bien las situaciones de OOM
      Sé que se pueden poner barandales con cgroups, instalar earlyoom, aumentar el swap o usar zram
      Pero al final todo eso no deja de ser un conjunto de hacks sucios que a veces te pueden salvar una vez, y no arreglan la forma en que se manejan estas situaciones
      Ojalá dejaran de presentar eso como solución
      He visto al kernel no poder asignar memoria en dm_crypt y que un volumen LUKS se monte a sí mismo como solo lectura; por favor, basta con matar un proceso de espacio de usuario
      El estado actual es inaceptable y ya cansan las excusas
    • Me pregunto si probaste zswap/zram
      Con zstd puedes usar 8 GB de RAM como si fueran 20 GB de “RAM”, o 16 GB como 40 GB, sin demasiados problemas
      Incluso puedes ser más agresivo y sobrecomprometer la memoria por encima del 100%; Android también lo hace así, así que es un enfoque bastante estable

  • Buena noticia
    Los drivers gráficos de AMD en Linux en general me han funcionado bien, pero este problema fue una excepción que me tocó varias veces

    • Yo tuve un poco menos de suerte
      El problema que estoy teniendo últimamente es que, después de despertar de la suspensión, el driver empieza a llenar el log con "[drm] scheduler comp_1.0.n is not ready, skipping" después de WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu]
      https://gitlab.freedesktop.org/drm/amd/-/issues/3911
    • Yo también he tenido una buena experiencia en general, pero si desconecto el Thunderbolt al que está conectado el monitor mientras el equipo está dormido, aparece un problema parecido
      Aunque, al ser una laptop, la configuración del driver es muy distinta y tampoco hay GPU PCIe

  • La parte en la que guardó y extrajo el módulo del kernel amdgpu.ko, lo descompiló con Ghidra y luego mapeó la ubicación del crash de dm_resume a la línea correspondiente del código fuente del kernel es siempre mi escena favorita de la depuración