An IRQ, or interrupt request, is a signal that tells your computer’s processor to pause what it’s doing and handle something more urgent. Every time you press a key, move your mouse, or receive data from a network card, an IRQ fires to get the processor’s attention. Without interrupts, your CPU would have to constantly check every device to see if it needed anything, wasting enormous amounts of processing power.
How an IRQ Works
Think of an IRQ like a doorbell. Instead of walking to the door every few seconds to check if someone’s there, you wait for the bell to ring and then respond. Hardware devices use the same principle: they send a signal only when they actually need the processor to do something.
When an IRQ fires, the processor saves its current state (what it was working on and where it was in that task), then jumps to a specific piece of code called an interrupt handler. That handler deals with the device’s request, whether it’s reading a keystroke or processing incoming network data. Once the handler finishes, the processor restores its previous state and picks up right where it left off. This entire process happens in microseconds, so you never notice the pause.
An interrupt controller sits between your devices and the processor, managing which signals get through and in what order. This is important because multiple devices might need attention at the same time, and some requests (like a system timer tick) are more critical than others.
Hardware vs. Software Interrupts
Hardware interrupts come from physical devices: a keyboard, a disk drive, a network adapter. These are the classic IRQs that most people mean when they use the term. They’re triggered by electrical signals, either from a device inside the computer or from an external port.
Software interrupts are different. They’re triggered by instructions within a program rather than by a physical signal. Operating systems use them heavily for system calls, which is how a regular application requests something that requires higher privileges, like reading a file from disk or sending data over the network. A program running in normal mode triggers a software interrupt, which elevates the processor to a privileged mode so the operating system kernel can safely handle the request. Debuggers also use software interrupts: on x86 processors, a special instruction called INT3 triggers a trap that lets a debugger pause and inspect a running program.
The Classic IRQ Assignments (0 Through 15)
Older PCs used a chip called the 8259 Programmable Interrupt Controller, which originally provided only 8 interrupt lines. That wasn’t enough, so manufacturers cascaded two of these chips together to get 15 usable lines (one line was consumed by the connection between the two chips). Each line was hardwired to a specific device type. These assignments became a standard that persisted for decades:
- IRQ 0: System timer
- IRQ 1: Keyboard
- IRQ 2: Cascade link to IRQs 8 through 15
- IRQ 3: Second serial port (COM2)
- IRQ 4: First serial port (COM1)
- IRQ 5: Sound card or parallel port
- IRQ 6: Floppy disk controller
- IRQ 7: First parallel port (printer)
- IRQ 8: Real-time clock
- IRQ 9: Power management (ACPI) or general peripherals
- IRQ 10: Open for peripherals like network or SCSI cards
- IRQ 11: Open for peripherals
- IRQ 12: PS/2 mouse
- IRQ 13: Math co-processor
- IRQ 14: Primary hard drive channel
- IRQ 15: Secondary hard drive channel
If you’ve ever heard someone talk about “IRQ conflicts” on older hardware, this is why. With only 15 lines available and many of them already claimed, adding a new sound card or network adapter often meant two devices fighting over the same interrupt. That could cause one or both devices to stop working until you manually reassigned them.
How Modern Systems Handle Interrupts
The old 15-line limit is essentially gone on modern computers. Two major changes made it obsolete.
First, the Advanced Programmable Interrupt Controller (APIC) replaced the legacy 8259 chip starting with Intel’s Pentium processors. The APIC supports up to 256 interrupt vectors instead of 15, and it’s designed for multi-core processors. Each processor core has its own local APIC, which means the system can route interrupts to specific cores rather than funneling everything through a single point. This is critical for performance on today’s machines, where processors commonly have 8, 16, or more cores.
Second, PCI Express devices now use Message Signaled Interrupts (MSI) instead of physical pin lines. Rather than toggling a dedicated electrical pin, a device triggers an interrupt by writing a value to a specific memory address. The extended version, MSI-X, lets a single device support up to 2,048 different interrupt messages, each independently controllable. This eliminates the old sharing and conflict problems entirely, because devices no longer compete for a limited number of physical wires.
IRQ Sharing
Even before MSI became the norm, PCI devices could share interrupt lines. On a typical PCI bus, all devices shared just 4 interrupt pins. The system BIOS builds a routing table that maps each PCI device to a specific interrupt number and slot combination, creating a unique “link value” for each device. This lets the operating system tell devices apart even when they’re on the same IRQ line.
Sharing generally works fine, but it adds a small amount of overhead because the processor has to check each device on a shared line to figure out which one actually sent the interrupt. This is one reason MSI is preferred on modern hardware: each device gets its own dedicated interrupt path, so there’s no ambiguity.
Checking IRQ Assignments on Your System
On Windows, you can view IRQ assignments through Device Manager. Open it, select a device, go to its Properties, and look under the Resources tab. You’ll see which IRQ number the device is using. Windows also handles IRQ steering automatically, dynamically reassigning interrupts based on its own routing logic rather than relying solely on BIOS assignments. In rare cases where this causes problems (a device not working or the system hanging), you can disable IRQ steering to let the BIOS handle assignments instead.
On Linux, the file /proc/interrupts gives you a real-time view of every interrupt on the system. The first column is the IRQ number. The next columns show how many times each CPU core has handled that interrupt. The final columns list the interrupt type and the device name. You’ll typically see entries labeled “IO-APIC-edge” (triggered once when a signal transitions from low to high) or “IO-APIC-level” (triggered continuously while a signal stays high). On very old systems, you might see “XT-PIC,” which indicates the legacy 8259 controller is in use.
Why IRQs Still Matter
For most users, IRQs work invisibly in the background and never need attention. Modern operating systems and hardware handle interrupt routing automatically. But IRQs become relevant when you’re troubleshooting a device that isn’t responding, diagnosing system performance issues, or working with embedded hardware where interrupt assignments are configured manually. High interrupt rates on a specific CPU core, visible in Linux’s /proc/interrupts, can indicate a bottleneck. And in real-time or performance-critical systems, tuning how interrupts are distributed across cores can meaningfully reduce latency.