Cómo identificar y solucionar conflictos de IRQ entre dispositivos de hardware antiguos

Inicio » Hardware » Cómo identificar y solucionar conflictos de IRQ entre dispositivos de hardware antiguos

Cuando empiezas a notar que un dispositivo deja de funcionar al instalar una nueva tarjeta (una gráfica grande, una vieja tarjeta de sonido PCI, una controladora extra…), es bastante probable que estés delante de un problema clásico: un conflicto de IRQ o de otros recursos de hardware. Aunque hoy parezca cosa de la prehistoria informática, en equipos con hardware antiguo o tarjetas PCI veteranas todavía puede dar mucha guerra.

En este artículo vamos a ver, con calma pero al grano, qué son las IRQ, cómo se gestionan en sistemas modernos y antiguos, por qué siguen pudiendo chocar entre sí y, sobre todo, cómo identificar y resolver conflictos cuando algo tan básico como una tarjeta de sonido o un puerto deja de responder después de ampliar el PC.

Qué es exactamente una IRQ y por qué importa tanto

Una interrupción de hardware o IRQ (Interrupt ReQuest) es, en esencia, una señal que un dispositivo envía al procesador para decirle: “eh, necesito atención ahora mismo”. Esa señal llega por una línea física (un cable o pista en la placa) o como un mensaje especial (MSI, Message Signaled Interrupt) en sistemas más modernos.

Cuando una CPU tiene las interrupciones habilitadas y recibe una IRQ, detiene temporalmente la ejecución del código actual, guarda su contexto y salta a una rutina especial del sistema operativo llamada ISR (Interrupt Service Routine o rutina de servicio de interrupción). Esa ISR atiende al dispositivo: reconoce la interrupción, descarta duplicados si es necesario y suele programar trabajo diferido para terminar el procesamiento sin bloquear la CPU más tiempo del imprescindible.

En sistemas tipo PC clásico, las IRQ estaban gestionadas por uno o varios controladores de interrupciones programables (PIC). Hoy en día, se usan controladores mucho más avanzados (como APIC y variantes), pero la idea de fondo es la misma: hay varias líneas de IRQ, con diferentes niveles de prioridad, que se reparten entre los periféricos.

Un detalle importante es que cada interrupción tiene asociada una entrada en una tabla de vectores, donde se almacena la dirección de la rutina que debe ejecutarse cuando se activa esa IRQ. En arquitecturas antiguas, esta tabla estaba muy ligada al BIOS; en sistemas modernos, el sistema operativo y los drivers registran sus ISRs dinámicamente.

Cómo funciona el mecanismo de interrupciones paso a paso

Para entender por qué hay conflictos, conviene repasar, aunque sea a vista de pájaro, cómo gestiona la CPU una interrupción de hardware típica:

• Se termina la ejecución de la instrucción actual del proceso que está en la CPU.
• El procesador guarda en la pila su estado (registros, flags, contador de programa/IP) para poder retomar más tarde exactamente donde lo dejó.
• Consulta al controlador de interrupciones qué línea ha saltado y, con ese número de IRQ, busca la dirección de la ISR correspondiente en la tabla de vectores.
• Ejecuta la ISR, que atiende al dispositivo (leer un registro de estado, vaciar un buffer, programar trabajo diferido, etc.).
• Al finalizar, la ISR devuelve el control al sistema operativo, que restaura el contexto del proceso interrumpido y continúa como si no hubiese pasado nada.

En sistemas con muchas fuentes de interrupción, el controlador puede implementar prioridades. Por ejemplo, la interrupción del reloj del sistema (IRQ 0 en PCs clásicos) no se puede enmascarar y tiene prioridad máxima, porque de ella dependen el temporizador del sistema y la planificación de procesos.

También es posible que una rutina de interrupción sea interrumpida a su vez por otra IRQ de mayor prioridad. Esto se conoce como interrupciones anidadas. Para evitar el caos, el hardware permite deshabilitar temporalmente determinadas líneas (interrupciones enmascarables) mientras se gestiona una interrupción crítica.

Las 15 IRQ clásicas en PCs antiguos y sus usos típicos

En el mundo PC clásico (con PIC 8259 y compañía), el sistema manejaba un número muy limitado de IRQ de periféricos. Aunque las placas y chipsets modernos ampliaron este número y cambiaron el esquema interno, sigue siendo útil recordar el mapa “de toda la vida” para entender los conflictos con hardware antiguo:

• IRQ 0: reloj interno del sistema (muy alta prioridad).
• IRQ 1: teclado PS/2.
• IRQ 2: cascada hacia IRQ 8-15 (en pic secundario).
• IRQ 3: puerto serie COM2/COM4.
• IRQ 4: puerto serie COM1/COM3.
• IRQ 5: libre o antiguamente segunda tarjeta de sonido, red ISA, etc.
• IRQ 6: controlador de disquetera.
• IRQ 7: puerto paralelo LPT1.
• IRQ 8: reloj en tiempo real (CMOS).
• IRQ 9: libre / redirección de IRQ 2 en algunos sistemas.
• IRQ 10: libre (tarjetas SCSI, red, sonido…)
• IRQ 11: libre (muy típica para tarjetas PCI).
• IRQ 12: ratón PS/2 o dispositivo similar.
• IRQ 13: coprocesador matemático (FPU) en sistemas muy viejos.
• IRQ 14: primer controlador de disco duro (IDE primario).
• IRQ 15: segundo controlador de disco duro (IDE secundario).

Este mapa explica por qué, por ejemplo, usar simultáneamente COM1 y COM3 o COM2 y COM4 era una receta para el desastre: compartían la misma IRQ y el sistema no siempre sabía a cuál de los dos puertos correspondía la señal. En el mejor de los casos, uno de los dos dejaba de funcionar; en el peor, el sistema se colgaba.

Hoy muchos de estos puertos seriales (seriales, paralelo, disquetera…) han desaparecido o se exponen mediante controladoras USB, pero las tarjetas de sonido, de captura, controladoras antiguas PCI o algunos dispositivos embebidos pueden seguir dependiendo de este tipo de recursos fijos y generar conflictos.

Conflictos de IRQ, DMA y puertos de E/S: por qué se rompen las cosas

Un conflicto de IRQ ocurre cuando dos dispositivos distintos comparten la misma línea de interrupción sin estar diseñados para convivir. El resultado típico es que uno de ellos (o ambos) se comporta de forma errática: cuelgues, ruidos extraños en la tarjeta de sonido, bloqueos al inicializar el driver, etc.

Pero los problemas de recursos no se limitan solo a las IRQ. También pueden entrar en juego:

• Direcciones de E/S: rangos como 0x3F8 para COM1, que identifican registros de dispositivos. Si dos tarjetas pisan la misma zona, el sistema lee/escribe en el “dispositivo equivocado”.
• Canales DMA: líneas que permiten a un dispositivo acceder directamente a la memoria sin pasar por la CPU. Si dos periféricos comparten canal DMA, la corrupción de datos está casi garantizada.

En PCs de los 90 y primeros 2000 era normal que, al instalar una tarjeta de sonido ISA o PCI, el usuario tuviera que mover jumpers o editar parámetros de la BIOS para escoger IRQ, E/S y DMA que no chocaran con otros dispositivos. Si fallabas al elegir, venían los “fantasmas”: pitidos, ruidos, cuelgues, mensajes de error crípticos…

Un ejemplo muy típico: instalar una tarjeta de sonido que se enganchaba en IRQ 7, donde ya tenías la impresora en LPT1. Resultado: la impresora o la tarjeta de sonido (o ambas) funcionaban fatal hasta que ibas a la BIOS o movías jumpers para liberar esa IRQ.

IRQ y hardware moderno: por qué los conflictos son menos frecuentes

Con la llegada de PCI, PCIe, ACPI y Plug and Play, el sistema operativo y el firmware empezaron a encargarse de negociar y asignar dinámicamente las IRQ, las direcciones de E/S y los canales DMA. Además, muchas controladoras modernas de interrupciones permiten que varias funciones compartan la misma IRQ de forma ordenada, e incluso utilizan MSI (Message Signaled Interrupts) en lugar de líneas físicas.

En un PC actual con Windows o Linux bien configurado, rara vez verás un conflicto clásico de IRQ “puro y duro” entre dispositivos modernos. Sin embargo, esto deja de ser tan bonito cuando mezclas:

• Tarjetas PCI antiguas (por ejemplo, interfaces de audio profesionales con chips viejos).
• Placas base veteranas, con pocas líneas de PCI/PCIe y un diseño de recursos muy limitado.
• Dispositivos de alto consumo de recursos (como una GPU potente en una ranura PCIe x16) junto a varias tarjetas PCI/PCIe que comparten bus.

En esas circunstancias pueden reaparecer síntomas muy familiares: una de las tarjetas de sonido deja de funcionar en cuanto montas la gráfica nueva, se escuchan ruidos aleatorios, el driver falla al cargar o el sistema se vuelve inestable cuando todo está instalado a la vez.

En algunos casos, la única forma práctica de “negociar” con la placa es cambiar las tarjetas de ranura PCI, desactivar puertos antiguos (por ejemplo, paralelo o serie que no uses) desde la BIOS para liberar IRQ o reordenar qué ranuras comparten líneas entre sí según el manual de la placa.

Caso típico: tarjeta gráfica nueva y tarjeta de sonido PCI antigua

Un escenario muy real que ilustra perfectamente todo esto es el de quien monta una GPU potente (por ejemplo, una R9 290 o similar) en una placa base vieja con un par de tarjetas PCI de audio profesional. Tras instalar la gráfica, una de las interfaces deja de sonar o solo emite ruidos extraños.

En ese tipo de configuración, es bastante probable que:

• La placa base comparta líneas de IRQ y recursos de bus entre la ranura PCIe x16 y una o varias ranuras PCI.
• Al introducir la gráfica, se reorganicen las asignaciones de IRQ y direcciones de E/S, y una de las tarjetas de sonido quede compartiendo recursos de mala manera con la GPU o con otro dispositivo.
• El chipset simplemente no esté pensado para manejar cómodamente esa combinación tan exigente de tarjetas, sobre todo si es una placa con socket antiguo (por ejemplo 1366) y electrónica ya desfasada.

¿Sigue existiendo, por tanto, el concepto de “conflicto de IRQ”? Sí, aunque ahora se ve menos y suele ir mezclado con limitaciones de diseño de la placa y del bus. La forma de solucionarlo no siempre es trivial: a veces basta con cambiar ranuras, desactivar puertos serie/paralelo en la BIOS y dejarle al sistema más margen para repartir recursos; otras, la placa simplemente no da más de sí.

En placas veteranas, con pocas opciones en BIOS y un chipset poco amigable, puede que al final no te quede otra que replantear la plataforma: una placa base más moderna (y por tanto, casi seguro que también un CPU nuevo y RAM nueva) que gestione mejor múltiples tarjetas PCIe/PCI y que tenga un firmware ACPI más maduro.

Interrupciones en Linux: /proc/interrupts, afinidad y rendimiento

En Linux, la gestión de interrupciones está muy expuesta y eso es una ventaja enorme para diagnosticar problemas finos de hardware o de rendimiento. El archivo /proc/interrupts muestra, para cada IRQ, cuántas interrupciones ha manejado cada CPU, qué tipo de interrupción es y qué controladores están registrados para esa línea.

Visualizarlo es tan simple como ejecutar en una terminal:

cat /proc/interrupts

Cada fila representa un número de IRQ y cada columna, las interrupciones atendidas por cada núcleo. Al final de la línea verás el tipo (por ejemplo, MSI, level, edge…) y el nombre de los controladores que usan esa IRQ. Esto permite detectar, por ejemplo, si una tarjeta de red o una controladora de disco están concentrando demasiadas interrupciones en un solo núcleo, o si varios dispositivos sensibles comparten una misma IRQ y están saturados.

Las IRQ en Linux tienen una propiedad llamada afinidad (smp_affinity), que indica en qué núcleos puede ejecutarse la ISR de esa interrupción. Esta afinidad se configura mediante una máscara de bits en:

/proc/irq/NUMERO_IRQ/smp_affinity

El valor suele aparecer en hexadecimal, donde cada bit representa un núcleo de CPU. Por ejemplo, en un sistema de cuatro núcleos, el valor f (1111 en binario) indica que esa IRQ puede ser atendida por cualquier CPU. Si cambias el valor a 1, limítas la interrupción al núcleo 0; si pones a (1010 binario), a los núcleos 1 y 3, y así sucesivamente.

Este ajuste es muy útil cuando quieres optimizar rendimiento en servidores o estaciones de trabajo, alineando la afinidad de las IRQ con la afinidad de los hilos de tus aplicaciones. Por ejemplo, hacer que la IRQ de una tarjeta de red se atienda en el mismo núcleo donde corre un proceso intensivo de red para mejorar la localización de caché.

Otros recursos en Linux: DMA, puertos de E/S y Sysfs

Además de las interrupciones, Linux expone otros recursos de hardware en el pseudo-sistema de ficheros /proc:

• /proc/dma: muestra los canales DMA asignados a dispositivos que todavía dependen de este mecanismo clásico de acceso directo a memoria.
• /proc/ioports: lista los rangos de direcciones de E/S ocupados por cada dispositivo o controlador.

Para ver su contenido basta con:

cat /proc/dma

cat /proc/ioports

En sistemas actuales verás que buena parte del hardware moderno se gestiona mediante memoria mapeada (MMIO) y mecanismos más avanzados, pero estos archivos siguen siendo muy útiles cuando trabajas con controladoras antiguas, tarjetas de expansión viejas o configuraciones híbridas.

Otra pieza clave es sysfs, montado normalmente en /sys. Sysfs organiza la información de los dispositivos del sistema de forma jerárquica: por bus, por tipo, por relación con otros dispositivos, etc. Ahí puedes consultar atributos de hardware, estados, IDs de dispositivo, enlaces entre ellos y, en muchos casos, ajustar parámetros en caliente escribiendo en los ficheros adecuados (como la afinidad de IRQ u opciones de energía).

Coldplug, hotplug y cómo encajan en todo esto

Cuando se habla de gestión de hardware en Linux (y en general), vale la pena diferenciar:

• Coldplug: dispositivos que están conectados antes de encender el equipo. Se detectan y configuran durante el arranque, leyendo tablas ACPI, el firmware, buses como PCI, etc. Muchas tarjetas internas (PCI, PCIe, algunos controladores integrados) entran en esta categoría.
• Hotplug: dispositivos que puedes conectar y desconectar en caliente, como USB, Thunderbolt, muchas tarjetas PCIe modernas que soportan hotplug, etc. El sistema escucha eventos (por ejemplo, udev en Linux) y carga drivers o reconfigura recursos dinámicamente cuando detecta cambios.

Los conflictos de IRQ clásicos eran casi siempre cosa de coldplug en placas antiguas, donde la asignación de recursos quedaba fijada en el arranque y había poco margen de maniobra. En sistemas modernos, con hotplug extendido y un firmware decente, el sistema operativo suele reasignar recursos de forma bastante inteligente, aunque como hemos comentado, el hardware legado puede seguir liándola.

Cuando quieras investigar problemas con un dispositivo hotplug o coldplug en Linux, combinar la información de /proc (interrupts, dma, ioports) con lo que ves en /sys te da una foto muy completa de cómo está distribuido el hardware, qué comparte bus con qué, y si hay saturación en alguna línea de IRQ.

Cómo detectar y resolver conflictos de IRQ en hardware antiguo

Si sospechas que tu problema es un conflicto de IRQ entre dispositivos de hardware antiguos, puedes seguir una serie de pasos bastante razonables para acotar el origen:

• Quita tarjetas y puertos que no uses: abre la carcasa y, con el equipo apagado, retira tarjetas de expansión que no sean imprescindibles. Entra en la BIOS y desactiva puertos que no utilices (paralelo, serie, controladoras IDE antiguas, etc.) para liberar IRQ y recursos.
• Cambia las tarjetas de ranura: muchas placas asignan diferentes IRQ según la ranura PCI/PCIe utilizada. Reubicar una tarjeta de sonido PCI a otra ranura puede hacer que deje de pelearse con la GPU.
• Consulta la documentación de la placa base: los manuales suelen traer un esquema de cómo se reparten las IRQ entre ranuras (por ejemplo, PCI1 comparte con PCIe x1_1, la ranura PCI2 comparte con el USB, etc.). Usar estas tablas te permite colocar las tarjetas de forma más inteligente.
• Revisa en el sistema operativo las IRQ asignadas: en Windows, desde el administrador de dispositivos, Visor de eventos para diagnóstico; en Linux, con /proc/interrupts. Si ves tu tarjeta de audio y la GPU compartiendo exactamente la misma IRQ y sospechas inestabilidad, ya tienes una pista.
• Actualiza BIOS y drivers: un firmware viejo puede gestionar fatal el reparto de recursos. A veces, una actualización de BIOS mejora el soporte ACPI y reduce conflictos.

Si después de todo sigues con problemas, y especialmente si tu plataforma es muy antigua (por ejemplo, socket 1366 con controladoras PCI clásicas y una GPU moderna ocupando casi todo el chasis), probablemente estás chocando contra un límite estructural de la placa base. En esas condiciones, cambiar a una plataforma más reciente (nuevo socket, nueva placa, RAM moderna) puede ahorrarte muchas horas de pelea con IRQs y recursos.

Aun así, incluso en hardware viejo, dedicar un rato a limpiar puertos obsoletos, recolocar tarjetas y revisar asignaciones suele darte margen para que convivan dispositivos que, de primeras, parecían incompatibles.

En definitiva, los conflictos de IRQ no han desaparecido del todo: se han vuelto menos visibles para el usuario medio, pero cuando mezclas hardware veterano, tarjetas PCI exigentes y placas base antiguas, aparecen síntomas clásicos como ruidos en el audio, cuelgues o dispositivos que “desaparecen” al instalar otros. Conociendo cómo funcionan las interrupciones, cómo consultar /proc/interrupts, /proc/dma, /proc/ioports y sysfs en Linux, y aprovechando las opciones de la BIOS para desactivar puertos sobrantes y reorganizar ranuras, tienes muchas más papeletas de recuperar la estabilidad sin tener que cambiar medio PC de golpe.