¿Por qué Linus Torvalds ignoró a la IA y corrigió un fallo de Linux?

Linus Torvalds ha resuelto uno de esos errores informáticos que parecen escritos para poner a prueba la paciencia humana. El creador de Linux localizó un fallo en el controlador gráfico Intel Xe después de una larga sesión de depuración en la que utilizó inteligencia artificial como asistente. La paradoja llegó cuando la propia IA concluyó varias veces que el problema era prácticamente irresoluble y recomendó abandonar la búsqueda.

Torvalds no le hizo caso. Continuó probando, añadiendo código de diagnóstico y reiniciando el sistema hasta encontrar una causa sorprendentemente pequeña: donde el controlador utilizaba una función para redondear hacia arriba, debía redondear hacia abajo. El arreglo esencial cabía en una línea; llegar hasta ella exigió 24 parches de depuración y 18 arranques del kernel.

La anécdota tiene bastante más interés que el consabido duelo entre humano y máquina. De hecho, la IA ayudó mucho. Torvalds lo reconoce sin demasiadas ceremonias: hizo buena parte del trabajo pesado, generó instrumentación y analizó los resultados. Lo que falló fue otra cosa, quizá más importante: el criterio para decidir cuándo dejar de investigar.

Un fallo minúsculo capaz de dejar la pantalla negra

El problema estaba en el controlador Xe utilizado por determinadas GPU modernas de Intel. En concreto, Torvalds consiguió reproducirlo de forma consistente en hardware Battlemage G21 con 16 GB de memoria gráfica. El ordenador podía arrancar aparentemente bien y, al llegar al entorno gráfico, quedarse con una pantalla negra mientras GDM, el gestor de inicio de sesión de GNOME, entraba en un ciclo de reinicios.

La causa estaba lejos del síntoma. Muy lejos, de hecho.

Parte de la memoria de vídeo está reservada para CCS, un espacio empleado por el hardware para almacenar metadatos relacionados con la compresión. El controlador necesita conocer dónde comienza esa zona para no entregársela al sistema como VRAM disponible. El código hacía ese cálculo y después redondeaba la dirección hasta un múltiplo de 128 KB.

Ahí estaba la trampa.

Al redondear hacia arriba, el controlador podía declarar libre una pequeña porción de memoria que, en realidad, seguía perteneciendo al hardware de compresión. Era como pintar una plaza de aparcamiento sobre medio metro de la vía del tren: casi siempre quizá no ocurra nada; basta una coincidencia desafortunada para que el resultado sea bastante menos pintoresco.

En la máquina analizada por Torvalds, el error dejaba 2 KB de una página de memoria dentro del espacio que el controlador ofrecía como disponible. El hardware podía escribir después sus metadatos de compresión en ese fragmento. Y cuando allí terminaba alojada una tabla de páginas de la GPU, los datos quedaban corrompidos. El compositor gráfico fallaba, GDM volvía a arrancarlo y la pantalla parecía haberse rendido definitivamente.

El arreglo: de round_up() a round_down()

La modificación decisiva consistió en sustituir el redondeo ascendente por uno descendente ajustado al tamaño de página de 4 KB. Así, la frontera de la memoria utilizable queda situada antes de la zona reservada y el asignador de VRAM no puede entregar accidentalmente al software una página que contiene memoria de CCS.

En código, el cambio principal resulta casi cómico por su tamaño: round_up() pasó a ser round_down(). También se corrigió una comprobación interna que, paradójicamente, no estaba en condiciones de detectar precisamente el caso para el que parecía existir.

Es una de esas escenas clásicas de la ingeniería informática: diez horas mirando el motor, desmontando piezas y tomando medidas para terminar descubriendo un tornillo colocado al revés.

La IA quiso abandonar antes que Torvalds

Aquí aparece la parte que convirtió un oscuro error de controlador gráfico en una historia bastante ilustrativa sobre el desarrollo asistido por inteligencia artificial.

Torvalds explicó que había sido una sesión de depuración infernal y reconoció que la IA había resultado enormemente útil haciendo trabajo repetitivo. Pero el asistente también aseguró en varias ocasiones que el problema era imposible de resolver y llegó a proponer que se redactara simplemente un informe sobre el fallo.

Torvalds siguió insistiendo.

Su comentario tuvo el sarcasmo habitual: sugirió que aquellas herramientas quizá hubieran sido entrenadas con gente menos obstinada que él. Cuando recibía nuevas instrucciones, la IA continuaba obedientemente incorporando código de depuración y procesando la información obtenida. Finalmente, Torvalds incluso le permitió redactar buena parte del mensaje asociado al cambio.

No consta en el cambio publicado qué modelo concreto utilizó, un detalle importante frente a algunas interpretaciones que han atribuido el episodio a herramientas específicas sin una confirmación equivalente en el mensaje del propio Torvalds.

Mucho trabajo automático, una decisión humana

El episodio tampoco demuestra que la inteligencia artificial sea inútil programando. Más bien muestra algo bastante menos espectacular y probablemente más interesante: puede multiplicar la capacidad de experimentar sin sustituir necesariamente el juicio del investigador.

Añadir mensajes de diagnóstico, modificar temporalmente código, comparar registros y repetir pruebas son labores ideales para un asistente que no se cansa de escribir. Decidir que una hipótesis aparentemente absurda todavía merece otras seis comprobaciones pertenece a un terreno más resbaladizo: el del criterio técnico.

Torvalds tenía, además, una ventaja que difícilmente cabe resumir en una ventana de chat: décadas de conocimiento del kernel, intuición sobre cómo falla una máquina real y una elevada tolerancia a pasar horas persiguiendo una anomalía que aparece en un lugar y nace varios niveles más abajo.

El error llevaba unos dos años escondido

El código problemático procedía de un cambio introducido aproximadamente dos años antes. Durante mucho tiempo, el fallo solo se manifestaba de manera esporádica. Torvalds había observado episodios separados por meses y llegó a sospechar de distintas circunstancias de su configuración gráfica.

Su equipo tampoco era precisamente el ordenador convencional de una oficina: utilizaba una tarjeta gráfica discreta con 16 GB de VRAM y había trabajado con configuraciones de dos monitores 6K, rotaciones de pantalla y escalado fraccionario. Durante la investigación incluso pareció durante un tiempo que alguna de esas peculiaridades explicaba el comportamiento.

No era así.

Una actualización del espacio de usuario aparentemente cambió las condiciones suficientes para que el error, antes esquivo, comenzara a reproducirse prácticamente en cada arranque. Tener por fin un fallo repetible convirtió una sombra ocasional en algo que podía perseguirse con método. Torvalds pasó entonces más de diez horas sobre el problema hasta aislarlo.

Por qué reiniciar GDM podía hacer desaparecer el problema

Uno de los detalles más desconcertantes ayuda a entender por qué fue tan difícil encontrar la causa. Tras el arranque en frío, una tabla de páginas de una máquina virtual de Mesa podía terminar precisamente sobre la página parcialmente invadida por los metadatos CCS. El hardware escribía encima, la tabla quedaba dañada y el entorno gráfico se estrellaba.

Pero al reiniciar GDM, las nuevas estructuras podían asignarse en otra zona de la memoria. Y entonces funcionaba.

Ese comportamiento es veneno para cualquier depuración: el mismo sistema parece averiado y sano con pocos segundos de diferencia, mientras el código culpable se encuentra en un cálculo de memoria que aparentemente no guarda relación directa con el gestor gráfico que acaba cayéndose.

También explica otros síntomas que Torvalds había visto anteriormente, como cierta corrupción gráfica ocasional. Si la zona pisada contenía algo menos delicado que una tabla de páginas, el problema podía limitarse a dañar un mapa de bits u otros datos visuales. Si acertaba con una estructura crítica, en cambio, el escritorio desaparecía.

El fallo que enseña dónde termina la autoridad de una IA

La corrección fue incorporada al árbol principal de Linux y marcada también para las ramas estables afectadas. El desarrollo del kernel Linux 7.3 se encuentra en fase de candidatos de lanzamiento, con Linux 7.3-rc3 publicado el 13 de septiembre de 2026.

Pero la consecuencia más curiosa del episodio probablemente dure más que esa versión del kernel. No porque Torvalds haya demostrado que una persona puede vencer a una inteligencia artificial —esa lectura parece salida de una película barata—, sino porque mostró una distribución del trabajo bastante más realista.

La máquina produjo código, revisó resultados y alivió tareas tediosas. El humano decidió que la respuesta de la máquina no era una sentencia.

Y funcionó.

La IA aseguraba que habían llegado a un callejón sin salida. Torvalds siguió abriendo puertas hasta descubrir que todo aquel laberinto terminaba en una sola línea: había que redondear hacia abajo, no hacia arriba. Pocas historias explican con tanta economía qué puede aportar la inteligencia artificial al desarrollo de software y, al mismo tiempo, qué conviene no entregarle todavía: la última palabra.