Solución de Artefactos de Video en AMD con Debian: Actualización de Firmware y Paquetes

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 28 Visitas 11 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos para instalación, 1-2 horas para upgrade in-place.
Requisitos: Backup de /home, conexión a internet, 20+ GB libres.
Resultado: Sistema actualizado con soporte extendido, drivers funcionando.
Troubleshooting: dnf distro-sync, akmods para NVIDIA, journalctl -p err.

Qué pasó con la decodificación AV1 de AMD en Debian

Durante agosto y septiembre de 2026, miles de usuarios de Linux con GPUs AMD Navi (serie RX 6000/7000 y APUs Renoir) empezaron a ver bandas verticales y bloques de color moviéndose en videos de YouTube, archivos .webm AV1 y streams. El culpable fue una actualización del paquete linux-firmware — específicamente la versión 20260810-1 — que introdujo una regresión en el firmware de la GPU encargado de la decodificación por hardware del códec AV1.

El 18 de septiembre, un usuario de Debian sid abrió el bug #1148284 reportando el problema y enlazando al work item upstream en freedesktop.org/drm/amd. La discusión se había replicado en Arch (bbs.archlinux.org), CachyOS, Fedora y Reddit semanas antes. La solución llegó el 16 de septiembre con firmware-nonfree 20260916-1, mergeado por Ben Hutchings en el MR !154 del equipo kernel de Debian.

En este artículo cubrimos qué cambió en el firmware, cómo verificar si tu sistema está afectado, y cómo actualizar (o hacer rollback si lo necesitas) en Debian stable, testing, unstable y trixie-backports.

Por qué importa si tienes un servidor con GPU

El códec AV1 es ya el códec de facto en YouTube, Netflix y Twitch para resoluciones 1080p en adelante. Si administras un servidor multimedia (Plex, Jellyfin, Frigate con NVR, o nodos de transcoding con VA-API), la regresión no es un problema cosmético: transcodes fallan, se pierden frames, o el pipeline deffmpeg-VAAPI genera archivos de salida con artefactos. En estaciones de trabajo con sesiones remotas (Sunshine + Moonlight, RDP, escritorios remotos vía navegador) los artefactos hacen que la sesión sea inutilizable cuando el servidor entrega video codificado en AV1.

El síntoma visible es muy característico: bandas verticales o rectangulares que cambian de frame a frame, ligeramente más claras o más oscuras que el resto de la imagen. No es pixelado ni es congelamiento de imagen — es un corrimiento del color en bloques. En Firefox, Chrome, Brave, mpv y Haruna se reproduce igual. En Windows sobre el mismo hardware, no aparece. La firma es inequívoca.

Verificar si tu Debian está afectado

Antes de cambiar nada, confirma dos cosas: la versión de firmware que tienes instalada, y que el problema ocurre con tu GPU específica.

dpkg -l firmware-amd-graphics | tail -1
apt-cache policy firmware-amd-graphics

Si la versión instalada es 20260810-1 (o 20260810-1~bpo13+1 en trixie-backports), estás en la ventana de la regresión. Si tienes 20260622-1 o anterior, no estás afectado. La versión corregida es 20260916-1 o superior.

Para confirmar que la GPU usa decodificación por hardware AV1 (y no CPU), usa amdgpu_top mientras reproduces un video de YouTube en AV1:

sudo apt install amdgpu-top
sudo amdgpu_top

Busca la fila con un proceso RDD (Ring Doorbell / Decode): la columna VCNU debe mostrar un valor mayor a cero. Si VCNU está en cero y la columna VCN0 muestra actividad, el VCN engine está activo pero no se está usando la ruta AV1. Si CPU sube al 100% al reproducir AV1, no estás usando hardware decode y por eso no ves el bug — pero también estás perdiendo el beneficio de la decodificación por hardware.

Para hacer un test A/B rápido, reproduce el video de muestra de Elecard (CityHall 1920×1080) con mpv y hardware decode:

sudo apt install mpv
mpv --hwdec=vaapi https://www.elecard.com/storage/video/CityHall_1920x1080.webm

Si ves bandas verticales que se mueven, el firmware es el culpable. Si el video se ve limpio, el problema está en otro lado (driver Mesa, versión del kernel, configuración de VA-API).

Actualizar a la versión corregida

Para Debian unstable (sid) y testing (forky), Ben Hutchings subió firmware-nonfree 20260916-1 el 16 de septiembre. Si tu sistema ya apunta a unstable, el upgrade es directo:

sudo apt update
sudo apt install --only-upgrade firmware-amd-graphics
sudo reboot

El reboot es obligatorio: el firmware se carga en la GPU al inicio y solo se puede recargar con un reinicio completo. modprobe -r amdgpu no es suficiente porque el firmware se mantiene en la VRAM.

Para Debian 13 trixie, hay dos caminos según cuándo necesites el fix:

Opción A — trixie-backports (recomendado): El 16 de septiembre se subió 20260810-1~bpo13+1 a backports. Si bien esa versión todavía tiene la regresión, el paquete firmware-nonfree en backports se actualiza más rápido que stable. Para apuntar a backports:

echo 'deb http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware' | 
  sudo tee /etc/apt/sources.list.d/trixie-backports.list
sudo apt update
sudo apt install -t trixie-backports firmware-amd-graphics
sudo reboot

Opción B — esperar al point release de trixie: El próximo point release de Debian 13 (trixie) incluirá 20260916-1 en la rama principal. La cadencia típica de point releases de Debian es cada 2-3 meses, así que podrías esperar hasta noviembre o diciembre de 2026. Si la regresión no te afecta de forma crítica (no tienes un servidor de medios en producción, o puedes tolerar los artefactos), esta es la opción más conservadora.

Para Debian 12 bookworm, estás en LTS y el kernel/firmware se actualiza por la rama bookworm-security. La versión 20260916-1 no va a llegar a bookworm automáticamente porque bookworm congeló sus versiones en 2025. Si necesitas el fix en bookworm, instala el paquete desde trixie-backports modificando el source.list (no recomendado en servidores en producción sin testing previo).

Rollback de emergencia a firmware funcional

Si tienes un servidor en producción que no puedes reiniciar ahora mismo, o si el upgrade desde backports te trajo una versión que no es la que esperabas, puedes hacer rollback temporal a 20260622-1, la última versión conocida como funcional. Descárgalo del snapshot de Debian:

mkdir -p /tmp/firmware-rollback
cd /tmp/firmware-rollback
wget http://snapshot.debian.org/archive/debian/20260810T000000Z/pool/main/f/firmware-nonfree/firmware-amd-graphics_20260622-1_all.deb
sudo dpkg -i firmware-amd-graphics_20260622-1_all.deb
sudo reboot

El paquete dpkg -i instala sin tocar las dependencias de APT, así que el próximo apt upgrade no te va a devolver a la versión rota automáticamente. Cuando estés listo para actualizar, sudo apt install --only-upgrade firmware-amd-graphics y reboot.

Si el rollback no es opción porque ya tienes 20260916-1 y por alguna razón los artefactos siguen apareciendo, el problema no es el firmware — probablemente es un driver Mesa desactualizado. Verifica:

dpkg -l mesa-va-drivers mesa-vulkan-drivers libva-mesa-driver

Mesa 25.x y 26.x son los que dan soporte completo a VCN 4.0 (Navi 22/23/24) y VCN 5.0 (RDNA 3). Si tienes Mesa 24.x, considera actualizar antes de tocar el firmware de nuevo.

El fix desde el lado del kernel: VCN 5.0 y patches KVM

El bug original estaba en el firmware, pero Ben Hutchings también mergeó en septiembre una batería de cambios en el kernel Linux de Debian que vale la pena conocer. Los más relevantes para servidores con GPU:

MR !2010 — Backport de fixes de seguridad para KVM en arquitecturas x86, dentro del LTS.
MR !2108 — Re-habilitar CONFIG_COMPACTION en alpha (afecta solo a esa arquitectura, pero quedó cerrado).
MR !2109 — Habilitar soporte para BMI323 (sensor IMU de Bosch) como módulo. Relevante si usas laptops con sensor de presencia.
MR !2110 — Update de configuración riscv64 para Linux 7.3.

El kernel en trixie-backports recibió 7.1.13-1~bpo13+1 y 7.2.6-1~bpo13+1 durante septiembre. Si tu hardware es muy nuevo (RDNA 4 / Strix Halo) y los drivers RDNA 3 no te dan decodificación AV1 estable, vale la pena saltar a 7.2.x en lugar de quedarte en el LTS 6.1.x o 6.12.x.

Para linux-6.12 LTS, el 19 de septiembre se subió 6.12.107-1~deb12u1 a bookworm-security, con merge de cambios desde el 6.12.111-1 de trixie. Si mantienes bookworm con LTS, este kernel trae los fixes de seguridad pendientes; el firmware sí lo tienes que actualizar aparte (no viene en el meta-paquete del kernel).

Troubleshooting de problemas residuales

Si después de actualizar a 20260916-1 y reiniciar, todavía ves artefactos en videos AV1 específicos, hay tres causas probables, en orden de frecuencia:

1. Firefox con cache de sesión vieja. El navegador cachea el codec string y el contenedor del video. Solución: abrir about:support, hacer clic en “Reiniciar con los complementos desactivados…”, reproducir el video, y verificar. Si se ve limpio, era cache. Si sigue roto, problema de driver.

2. Mesa no actualizado. El firmware de la GPU y el driver Mesa son dos capas distintas. El firmware maneja el “cómo” se decodifica el bitstream a nivel de hardware; Mesa maneja la API VA-API/Vulkan que el navegador o el reproductor usan. Si tienes Mesa 24.x y firmware 20260916, vas a tener un desbalance: Mesa espera un comportamiento de firmware que el binario nuevo no expone. Solución:

sudo apt install --only-upgrade mesa-va-drivers mesa-vulkan-drivers libva-mesa-driver
sudo reboot

3. Videos específicos con perfil AV1 no soportado. YouTube usa AV1 Main Profile nivel 4.0/5.0/5.1, y algunos canales suben videos con AV1 High Profile (nivel 6.0+) o con particionamiento no estándar. Si la regresión AV1 se manifiesta solo en ciertos canales y no en otros, es probable que sea perfil no soportado, no regresión. Workaround en Firefox: about:config, buscar media.av1.enabled y dejarlo en true, pero considerar media.av1.use-scene-content-detection en true para evitar fallback a H.264 en streams sospechosos.

Si nada de lo anterior funciona y necesitas video AV1 funcional hoy, la salida es desactivar el codec en Firefox temporalmente:

# En about:config:
# media.av1.enabled → false
# Reiniciar Firefox

El navegador va a negociar con YouTube un códec alternativo (VP9, H.264). Pierdes ~20% de eficiencia de compresión pero el video se ve perfecto. Cuando Mesa y el firmware estén alineados en el futuro, puedes volver a habilitar AV1.

Verificación final y monitoreo

Después de hacer el upgrade, espera 24 horas y revisa los logs del kernel por errores relacionados con el driver amdgpu:

journalctl -k -g amdgpu -g VCN -g AV1 --since "1 day ago"

Si ves líneas con VCN y decode mencionadas pero sin errores fatales (amdgpu 0000:XX:XX.X: amdgpu: DPU o ring timeout), el sistema está saludable. Si ves ring SDMA0 timeout o GPU fault, hay un problema de stability del driver que va más allá del firmware — abre un bug en freedesktop.org/drm/amd con la salida completa de sudo journalctl -k -b y cat /proc/cpuinfo.

Para servidores de medios con Jellyfin o Plex, activa el log de VA-API en el servicio antes del reboot:

# /etc/environment
LIBVA_MESSAGING_LEVEL=2
MESA_DEBUG=quiet
LIBVA_DRIVER_NAME=radeonsi

Después del reboot, cualquier intento de decode que falle va a quedar en journalctl -u jellyfin con la razón exacta (perfil AV1 no soportado, buffer overflow, rate control mal configurado).

Cuándo NO actualizar (todavía)

Hay dos escenarios donde te conviene esperar antes de instalar 20260916-1:

Sistemas congelados para certificación. Si tu servidor está bajo una configuración certificada (HIPAA, PCI-DSS, alguna norma interna), cambiar el firmware de la GPU requiere re-validación. espera al próximo ciclo de patching de tu organización.

Hardware muy viejo (pre-RDNA 1). Si tienes una RX 400/500 series (Polaris, Ellesmere, Baffin), el firmware AV1 no te afecta directamente porque esas GPUs no tienen VCN 3.0+ (la unidad de decodificación AV1 por hardware empezó con RDNA 2 / Navi 24). Actualizar a 20260916-1 no te rompe nada, pero tampoco te arregla nada. espera a que tu próximo ciclo de mantenimiento lo incluya naturalmente.

Resumen del incidente y lecciones operativas

El bug AV1 de septiembre fue un buen ejemplo de cómo un cambio en firmware —una capa que muchos sysadmins ni saben que se actualiza independientemente del kernel— puede degradar servicios críticos de forma silenciosa. La cadena causal fue: linux-firmware 20260810 introduce regresión en VCN, Mesa 26.1.x confía en la nueva ABI, Firefox/Chrome/mpv reciben video AV1 pero la GPU decodifica con tablas corruptas, y el resultado es video visiblemente roto sin que ningún log marque error grave.

Tres prácticas que reducen el riesgo la próxima vez: fija con apt-mark hold durante las dos semanas posteriores a un point release, suscríbete a debian-kernel para enterarte de los merge requests de firmware, y ten siempre un snapshot local de /lib/firmware/amdgpu/ pre-update para rollback rápido (no todo el mundo puede hacer un wget desde el servidor en producción).

Si tienes experiencia con este bug en hardware específico (RX 6600, RX 7800 XT, APU Phoenix, etc.), los comentarios están abiertos. Cuanto más detallada sea la salida de amdgpu_top y journalctl que compartas, más útil va a ser para el próximo que esté diagnosticando lo mismo.

Preguntas frecuentes

¿Por qué Solución de Artefactos de Video en AMD con Debian: Actualización de Firmware y Paquetes 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 Solución de Artefactos de Video?

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 Solución de Artefactos de Video?

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 Solución de Artefactos de Video 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 Solución de Artefactos de Video?

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.