Corrección de DRM en Linux 7.3-rc5: Intel Xe throttle reason, Nouveau R570 y bugs detectados por IA

septiembre 29, 2026 Alfonso Moreno | Sysadmin Senior 38 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué se anunció esta semana

El domingo 27 de septiembre de 2026 Linus Torvalds publicó Linux 7.3-rc5, el quinto release candidate del próximo kernel estable, y de nuevo la rama DRM (Direct Rendering Manager) llega cargada. David Airlie, co-mantenedor del subsistema, envió el pull request con la mayor parte de los fixes acumulados durante la semana y el resumen que dejó en la lista de correo es directo: la mayoría son “AI inspired fixes for error handling paths, leaks and use after frees”, pero entre todo ese material rutinario se esconden tres cambios que sí merecen tu atención si administras servidores Linux con GPU Intel, NVIDIA, o AMD recientes.

El primero es el nuevo bit de hardware PWRBRK (power brake) que Intel reporta desde su próxima generación de aceleradores Crescent Island: el driver Xe ahora sabe por qué una GPU se está limitando, no solo que se está limitando. El segundo es la limpieza que el driver Nouveau necesitaba tras la migración de firmware R535 a R570 que rompió suspend/resume en tarjetas NVIDIA. Y el tercero, más sutil pero muy relevante, es la confirmación de que los LLM/AI agents ya son una fuente constante de descubrimiento de bugs en el kernel, no una moda pasajera.

Intel Xe: ahora sabemos por qué la GPU se frena

Si tienes un servidor con GPU Intel Arc, Data Center GPU Flex, o el próximo Crescent Island, y has visto thermal throttling en dmesg o en los logs de telemetría, hasta ahora solo veías el evento: la GPU se limitó. Con el driver Xe actualizado en 7.3-rc5 el mensaje incluye la causa específica que el hardware reporta a través del bit PWRBRK: temperatura media del SoC, thermal de memoria VR, o freno de potencia explícito del sistema.

En la práctica esto significa que cuando un job de inferencia empiece a degradarse en producción, vas a poder distinguir entre “la GPU está caliente” y “el sistema pidió frenar a propósito” sin abrir la caja y medir con multímetro. Para sysadmins que manejan cargas de IA on-premises o workstations de cálculo, esa diferencia cambia el plan de acción: cooling, BIOS, o conversación con el equipo que pide más potencia.

Nuevo en Intel Xe: lectura de throttle reason

El subsistema de telemetría del driver Xe ya exponía varias razones (memoria, VR, etc.) y ahora suma power brake como categoría propia. Crescent Island introduce el bit PWRBRK en su hardware; el driver lo propaga al espacio de usuario para que las herramientas de monitoreo lo reporten.

# Verifica la versión del driver Xe cargada en tu sistema
modinfo i915 | grep -E "^version|^description"
# Salida esperada en kernel 7.3+: descripción incluye "Crescent Island power brake"
# Confirma que el módulo reconoce tu GPU
ls /sys/class/drm/
# Deberías ver card0, card1, etc. según cantidad de GPUs
# Lee las razones de throttle del último evento
cat /sys/class/drm/card*/device/drm/*/perf/throttle_reason 2>/dev/null
# En 7.3+ aparece PWRBRK cuando el hardware lo reporta

El comando throttle_reason viene del sysfs del driver, así que no necesitas instalar utilidades adicionales. Si tu kernel es anterior a 7.3-rc5, ese archivo simplemente no existe y la lectura devuelve vacío o error de permisos. Eso es la señal: toca actualizar.

Nuevo suspend/resume para Nouveau tras el salto R535 a R570

Nouveau, el driver open source de NVIDIA, venía arrastrando una regresión heredada de cuando el proyecto migró de los firmware binaries R535 a los R570. El cambio fue necesario porque NVIDIA dejó de mantener R535, pero dejó suspend/resume roto en varias GPUs modernas. Los fixes de esta semana cierran esa herida.

Para quienes usan Nouveau (no el driver propietario de NVIDIA), lo concreto es que el ciclo suspend-to-RAM y resume vuelve a funcionar sin necesidad de reiniciar el módulo o recargar firmware a mano. También se corrigió el pinning de vRAM que afectaba workloads de cómputo con buffers grandes.

Verificar Nouveau y estado del firmware

Antes de actualizar kernel, confirma qué firmware está cargado ahora y compara después del reboot con 7.3-rc5.

# Identifica si tu sistema usa Nouveau o el driver propietario NVIDIA
lspci -k -s $(lspci | awk '/VGA|3D/{print $1; exit}') | grep -E "Kernel driver|Kernel modules"
# Si ves "nouveau", lista el firmware cargado actualmente
ls /lib/firmware/nvidia/ 2>/dev/null | head -20
# R535 vs R570: los nombres de archivo y los números de versión cambian
# Test rápido de suspend/resume (ejecutar con cuidado en producción)
sudo systemctl suspend
# Espera 30 segundos y reanuda
sudo systemctl resume
# Verifica que la sesión gráfica (Wayland/X11) sigue activa
echo $DISPLAY

En producción, prueba suspend/resume primero en un host de staging. Aunque los fixes apuntan a cerrar la regresión, cada hardware NVIDIA tiene sus particularidades y no es la primera vez que un fix de DRM genera regresiones nuevas en GPUs que antes andaban bien.

El elefante en la sala: AI agents encontrando bugs en el kernel

Airlie fue explícito al describir el pull: “AI inspired fixes for error handling paths, leaks and use after frees”. No es marketing. El mismo Torvalds mencionó en el anuncio de 7.3-rc5 que el codebase, con casi 41 millones de líneas, sigue descubriendo issues nuevos en parte gracias a LLM agents que automatizan la búsqueda de patrones problemáticos.

Para sysadmins esto importa por dos razones. La primera: el flujo de fixes en kernels modernos va a seguir siendo denso durante todo 2026 y 2027, lo que implica ciclos de actualización más cortos si quieres mantenerte al día con hardware nuevo. La segunda: si tu organización usa AI agents para auditar código propio, el kernel Linux es el ejemplo vivo de que la técnica funciona a escala, aunque necesita revisión humana constante.

Cómo preparar tu sistema para Linux 7.3

La fecha objetivo del estable es el 18 de octubre de 2026. Si administras servidores en producción, este es el plan que recomiendo antes de que aparezca el release final.

Plan de upgrade para servidores en producción

No saltes directo a 7.3 sin probar. El flujo seguro sigue siendo el mismo que en kernels anteriores: rc5 en staging, rc6/rc7 cuando aparezcan, y estable en un subconjunto de hosts antes del rollout masivo.

# En Debian/Ubuntu con mainline PPA o kernel.org
sudo apt install linux-image-7.3.0-rc5-generic linux-headers-7.3.0-rc5-generic
# En Fedora/RHEL con rawhide o COPR de testing
sudo dnf install kernel-7.3.0-rc5
# En Arch (suele estar en [testing] muy rápido)
sudo pacman -U linux-7.3.0rc5-1-x86_64.pkg.tar.zst
# Reiniciar y verificar
uname -r
# Esperado: 7.3.0-rc5
# Validar drivers gráficos activos
dmesg | grep -iE "nouveau|xe|amdgpu|nvidia" | head -10

Antes de reiniciar el host, exportá el log de dmesg actual y la lista de módulos cargados. Después del reboot con 7.3-rc5, comparás ambos. Cualquier módulo que haya cambiado de versión o que muestre warnings de firmware missing es candidato a regresión.

Cómo revertir rápido si algo rompe

El kernel nuevo no borra el anterior en la mayoría de distros. Si Nouveau o Xe no levantan correctamente tras el upgrade, puedes volver al kernel previo desde GRUB.

# Lista los kernels instalados en Debian/Ubuntu
dpkg --list | grep linux-image
# Marca el kernel anterior como default en GRUB
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 7.2.0-generic"
# Actualiza grub y reinicia
sudo update-grub
sudo reboot
# En RHEL/Fedora, usa grubby
sudo grubby --set-default /boot/vmlinuz-7.2.0
sudo reboot

Si Nouveau queda completamente bloqueado en el arranque y no puedes ni llegar a GRUB, booteá con un live USB, montá la partición root, y editá /etc/default/grub para forzar el kernel anterior antes del próximo reinicio.

Problemas conocidos y qué mirar en los logs

Los fixes de esta semana cubren regresiones específicas, pero la historia del kernel Linux dice que cada merge de subsistema grande puede romper algo en hardware que no estaba en la lista de pruebas de los maintainers. Lo que recomiendo vigilar:

Firmware missing errors en Nouveau: si ves nouveau firmware failed to load en dmesg, probablemente falte un blob de firmware R570. Descargá el paquete nvidia-firmware-570 de tu distro o del repo linux-firmware.
Black screen en Intel Xe con Crescent Island emulado: en QEMU o entornos virtualizados, el driver puede intentar leer el bit PWRBRK de un dispositivo que no lo expone. Si ves pantalla negra tras el boot, agregá nomodeset temporalmente.
Regresión de rendimiento en AMDGPU: aunque no hubo fixes grandes de AMD esta semana, la interacción con cambios de scheduler (también hubo fixes de Cache Aware Scheduling) puede afectar cargas de cómputo GPU. Monitoreá FPS o tokens/segundo antes y después.

Cómo leer los eventos de throttle en journalctl

Una vez en kernel 7.3+, los eventos PWRBRK se registran en el log del kernel. Para auditarlos o enviarlos a un sistema de monitoreo (Prometheus + node_exporter, Loki, etc.), puedes filtrarlos directamente desde journalctl.

# Eventos de throttle de GPU Intel Xe desde el último boot
journalctl -k --grep="throttle_reason|PWRBRK|Xe driver" --no-pager
# Filtrar por fecha (últimas 24h)
journalctl -k --since="24 hours ago" --grep="throttle_reason"
# Si usas Promtail/Loki, exportar a archivo
journalctl -k --since="24 hours ago" --grep="throttle_reason" > /var/log/xe_throttle.log

El output de journalctl muestra la línea de log exacta con la causa del throttle. Combinado con métricas de temperatura (sensors o IPMI), puedes correlacionar qué evento de PWRBRK correspondió a qué pico térmico.

Verificar Nouveau tras el upgrade a 7.3

Después de reiniciar con el kernel nuevo, haz un check rápido para confirmar que Nouveau cargó firmware R570 y que suspend/resume responde. Esta rutina evita que te lleves la sorpresa en producción.

# Confirmá que Nouveau levantó con firmware R570
dmesg | grep -i "nouveau.*firmware|nouveau.*GR"
# Debe listar "Firmware version: 570..." en GPUs compatibles
# Test de suspend/resume no destructivo
echo deep > /sys/power/mem_sleep
sudo systemctl suspend
# Reanudar desde consola o wake-on-LAN
# Verificar que la sesión gráfica volvió
loginctl list-sessions

Si Nouveau no levanta el firmware R570 o el suspend falla, el log exacto te dice qué blob falta. Copiá las líneas relevantes antes de reportar el bug upstream al proyecto Nouveau en GitLab.

Vale la pena actualizar a 7.3

Si administras infraestructura con GPUs Intel o NVIDIA recientes, sí. Los fixes de throttle reason en Xe y la limpieza de suspend/resume en Nouveau son razones suficientes para planear el upgrade. Si solo tienes servidores headless sin GPU dedicada, puedes esperar al estable sin apuro: el resto del kernel (scheduler, networking, BPF) trae mejoras, pero ninguna crítica.

Para homelab y workstations donde Nouveau es importante porque no quieres el driver propietario de NVIDIA, el salto R570 + suspend/resume funcionando es la mejora más visible de este rc.

Resumen

Linux 7.3-rc5 trae más fixes de DRM de lo habitual y tres puntos concretos que importan a sysadmins: el driver Intel Xe ahora reporta por qué la GPU se throttlea (incluido el nuevo bit PWRBRK de Crescent Island), Nouveau recupera suspend/resume tras la migración R535 a R570, y queda claro que los AI agents ya son parte estable del flujo de descubrimiento de bugs. prueba el rc en staging, espera al estable del 18 de octubre, y mantené el kernel anterior instalado por si necesitas revertir.

Preguntas frecuentes

¿Por qué Corrección de DRM en Linux 7.3-rc5: Intel Xe throttle reason, Nouveau R570 y bugs detectados por IA es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Corrección de DRM en Linux?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Corrección de DRM en Linux?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Corrección de DRM en Linux y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Corrección de DRM en Linux?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.