Operating SystemsInterrupts

Interrupts: Hardware-Level I/O Signaling

LevelIntermediate

Duration90 mins

TopicInterrupts

5 / 5

Interrupt Acknowledgment

Completing the Interrupt Cycle

An interrupt is not truly complete when the handler finishes its work—the system must also inform the hardware that the event has been processed. This acknowledgment step is crucial: without it, the interrupt controller doesn't know the previous interrupt was handled, potentially blocking future interrupts or causing infinite interrupt loops.

Interrupt acknowledgment seems simple on the surface, but incorrect handling is responsible for a significant fraction of driver bugs: interrupt storms that freeze systems, lost interrupts that stall devices, and race conditions that corrupt data. Understanding acknowledgment mechanics is essential for reliable device driver development.

What You Will Learn

By the end of this page, you will understand the distinction between device-level and controller-level acknowledgment, master the timing requirements for proper acknowledgment, learn the specific EOI protocols for PIC and APIC, and recognize common acknowledgment-related bugs and their solutions.

Why Acknowledgment is Necessary

The interrupt acknowledgment mechanism exists because the CPU and the interrupt controller maintain state about in-progress interrupts. This state must be managed correctly to ensure proper interrupt delivery.

The Control Flow:

When an interrupt occurs:

Device asserts interrupt signal
Interrupt controller recognizes and prioritizes
Controller sends interrupt to CPU
CPU saves state and jumps to handler
Handler must acknowledge to both device AND controller
Controller updates its internal state
New interrupts can now be delivered

Without proper acknowledgment, two problems occur:

Missing Device Acknowledgment

•Device keeps interrupt line asserted
•Level-triggered: Interrupt fires again immediately after return
•Creates 'interrupt storm'
•CPU spends 100% time in handler
•System appears frozen
•Other devices cannot be serviced

Missing Controller EOI

•Controller thinks interrupt still pending
•Controller blocks equal/lower priority IRQs
•Subsequent interrupts never delivered
•Devices time out waiting for response
•System becomes progressively unresponsive
•May require hardware reset

Two-Level Acknowledgment:

Proper interrupt acknowledgment involves two distinct operations:

Device Acknowledgment: Tell the device to de-assert its interrupt signal (typically by clearing a status bit or reading a register)
Controller EOI (End of Interrupt): Tell the interrupt controller that the handler is complete and the CPU is ready for the next interrupt

Both must occur, often in a specific order, for correct operation.

Terminology Note

The term 'EOI' (End of Interrupt) specifically refers to the acknowledgment sent to the interrupt controller. Device acknowledgment varies by device and may be called 'clearing the interrupt', 'acknowledging the interrupt', or 'servicing the interrupt'. Don't confuse the two—both are necessary but serve different purposes.

Device-Level Acknowledgment

Each device has its own mechanism for acknowledging interrupts. The driver must understand the device's interrupt behavior and clear the interrupt condition appropriately.

Common Device Acknowledgment Patterns:

device_acknowledgment_patterns.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// Common device acknowledgment patterns
 
// Pattern 1: Write-to-Clear Status Register
// Most common pattern - write 1 to bit to clear it
irqreturn_t write_to_clear_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_BIT))
        return IRQ_NONE;  // Not our interrupt
    
    // Process the interrupt...
    handle_event(status);
    
    // Clear the interrupt by writing 1 to the status bit
    // (Write-1-to-clear is hardware convention for this pattern)
    writel(status & MY_INTERRUPT_BIT, dev->status_reg);
    
    return IRQ_HANDLED;
}
 
// Pattern 2: Read-to-Clear Data Register
// Reading data automatically clears interrupt
irqreturn_t read_to_clear_handler(int irq, void *dev_id) {
    // Simply reading the data register clears the interrupt
    uint32_t data = readl(dev->data_reg);
    
    // The read itself acknowledged the interrupt
    // Now process the data
    process_incoming_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 3: Separate Acknowledge Register
// Explicit acknowledge command to separate register
irqreturn_t explicit_ack_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_BIT))
        return IRQ_NONE;
    
    // Read data while interrupt is pending
    uint32_t data = readl(dev->data_reg);
    
    // Explicit acknowledge command
    writel(ACK_INTERRUPT, dev->interrupt_ack_reg);
    
    // Now process (after ack, new interrupts can queue)
    process_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 4: Auto-Clear on Handler Entry
// Hardware clears interrupt when vector is read
// Common with MSI - no explicit device ack needed
irqreturn_t msi_handler(int irq, void *dev_id) {
    // MSI interrupt is automatically acknowledged when
    // the CPU reads the vector from the interrupt controller
    // No explicit device acknowledgment needed!
    
    uint32_t data = readl(dev->data_reg);
    process_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 5: Multiple Interrupt Sources
// Device has multiple interrupt conditions
irqreturn_t multi_source_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->interrupt_status_reg);
    irqreturn_t ret = IRQ_NONE;
    
    if (status & RX_COMPLETE) {
        handle_rx_complete();
        writel(RX_COMPLETE, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    if (status & TX_COMPLETE) {
        handle_tx_complete();
        writel(TX_COMPLETE, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    if (status & ERROR_CONDITION) {
        handle_error();
        writel(ERROR_CONDITION, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    // Must clear ALL pending conditions before return
    // or interrupt will re-fire for remaining ones
    return ret;
}

Timing Considerations:

For level-triggered interrupts, the device acknowledgment must occur before the handler returns. Otherwise, the interrupt line remains asserted, and the CPU will immediately re-enter the handler upon executing IRET.

The critical window:

ack_timing.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// CORRECT timing for level-triggered interrupts
irqreturn_t correct_timing_handler(int irq, void *dev_id) {
    // 1. Identify interrupt source
    uint32_t status = readl(dev->status_reg);
    
    // 2. Capture any necessary data
    uint32_t data = readl(dev->data_reg);
    
    // 3. Clear device interrupt BEFORE returning
    writel(CLEAR_INTERRUPT, dev->status_reg);
    
    // 4. Now safe to do lengthy processing
    //    (IRQ line is now de-asserted)
    process_data_extensively(data);
    
    // 5. Return - no interrupt storm because line is clear
    return IRQ_HANDLED;
}
 
// INCORRECT timing - can cause interrupt storm
irqreturn_t incorrect_timing_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    uint32_t data = readl(dev->data_reg);
    
    // Do lengthy processing BEFORE clearing interrupt
    process_data_extensively(data);  // Takes 100+ microseconds
    
    // BUG: If we're preempted here, or if this is threaded,
    // interrupt can re-fire before we clear it
    writel(CLEAR_INTERRUPT, dev->status_reg);
    
    return IRQ_HANDLED;
}

Read Your Datasheet

Device acknowledgment mechanisms are device-specific and must be implemented according to the hardware datasheet. Assumptions based on 'common patterns' can lead to subtle bugs. Some devices require specific register access ordering, others have side effects on unrelated registers. Always consult the hardware documentation.

PIC End of Interrupt (EOI)

The Intel 8259 PIC requires an explicit EOI command after each interrupt. The EOI clears the corresponding bit in the In-Service Register (ISR), signaling that the handler has completed and lower-priority interrupts can now be delivered.

EOI Types:

8259 PIC EOI Command Types
EOI Type	Command Byte	Usage
Non-Specific EOI	0x20	Clears highest-priority in-service interrupt
Specific EOI	0x60 + IRQ#	Clears specific IRQ (0-7)
Auto EOI Mode	(initialization)	No EOI needed - clears on INTA

pic_eoi.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// 8259 PIC End of Interrupt handling
 
#define PIC1_CMD    0x20    // Master PIC command port
#define PIC2_CMD    0xA0    // Slave PIC command port
#define PIC_EOI     0x20    // Non-specific EOI command
 
// Standard PIC EOI - used by most interrupt handlers
void pic_send_eoi(uint8_t irq) {
    // If IRQ came from slave PIC, send EOI to both
    if (irq >= 8) {
        outb(PIC2_CMD, PIC_EOI);  // EOI to slave
    }
    outb(PIC1_CMD, PIC_EOI);      // EOI to master
}
 
// Why EOI order matters for slave PIC IRQs:
//
// For IRQs 8-15 (slave PIC):
// 1. Master PIC's IRQ2 (cascade) is set in master's ISR
// 2. Slave PIC's corresponding bit is set in slave's ISR
// 3. We must clear BOTH
//
// ORDER: Slave first, then master (or simultaneously)
// If we only EOI master, slave's ISR bit stays set
// -> Future slave IRQs blocked!
 
// Wrapper for interrupt handlers
irqreturn_t pic_irq_handler_wrapper(int irq, void *dev_id,
                                    irqreturn_t (*actual_handler)(int, void*)) {
    irqreturn_t ret = actual_handler(irq, dev_id);
    
    pic_send_eoi(irq);  // Always send EOI
    
    return ret;
}
 
// Example complete PIC interrupt handler
irqreturn_t keyboard_interrupt_handler(int irq, void *dev_id) {
    // 1. Read data from device (may also acknowledge device)
    uint8_t scancode = inb(KEYBOARD_DATA_PORT);
    
    // 2. Process the data
    process_keystroke(scancode);
    
    // 3. Send EOI to PIC
    pic_send_eoi(irq);  // IRQ1 for keyboard
    
    return IRQ_HANDLED;
}
 
// Specific EOI - when you need precise control
void pic_specific_eoi(uint8_t irq) {
    if (irq >= 8) {
        // Specific EOI for slave, then master IRQ2
        outb(PIC2_CMD, 0x60 + (irq - 8));  // Specific EOI to slave
        outb(PIC1_CMD, 0x60 + 2);          // Specific EOI for IRQ2
    } else {
        outb(PIC1_CMD, 0x60 + irq);        // Specific EOI to master
    }
}

When to Send EOI:

The EOI can be sent before or after processing, with different implications:

Early EOI (before processing):

Allows lower-priority interrupts to be delivered during processing
Handler can be preempted by any interrupt
Better for low-latency but requires reentrant handling

Late EOI (after processing):

Blocks lower-priority interrupts until handler completes
Traditional approach for simpler, non-reentrant handlers
Higher interrupt latency for other devices

Auto-EOI Mode

The PIC can be programmed for Auto-EOI mode, where the interrupt is automatically acknowledged when the CPU completes the INTA cycle. This simplifies handler code but removes the ability to control when low-priority interrupts are unmasked. Auto-EOI is rarely used in practice because it complicates interrupt prioritization.

APIC End of Interrupt

The Local APIC simplifies EOI handling compared to the PIC—a single write to the EOI register signals completion. The APIC automatically determines which interrupt is being acknowledged based on its internal state.

APIC EOI Mechanism:

apic_eoi.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// APIC End of Interrupt handling
 
// Local APIC register offsets (memory-mapped)
#define APIC_EOI_OFFSET     0x0B0   // EOI Register
 
// APIC base address (default, can be relocated)
#define APIC_DEFAULT_BASE   0xFEE00000
 
// x2APIC MSR for EOI
#define MSR_X2APIC_EOI      0x80B
 
// Standard APIC EOI (memory-mapped xAPIC)
static inline void apic_eoi(void) {
    // Write any value to EOI register
    // The value is ignored; the write itself triggers EOI
    volatile uint32_t *eoi_reg = (volatile uint32_t *)
        (APIC_DEFAULT_BASE + APIC_EOI_OFFSET);
    *eoi_reg = 0;
}
 
// x2APIC mode EOI (MSR-based, faster)
static inline void x2apic_eoi(void) {
    // Write to MSR is faster than memory-mapped access
    wrmsr(MSR_X2APIC_EOI, 0);
}
 
// What the APIC does on EOI:
// 1. Finds highest-priority bit set in ISR (In-Service Register)
// 2. Clears that bit
// 3. For level-triggered: checks if IRR (Request Register) has same vector
//    If so, re-delivers immediately (device didn't deassert)
// 4. Updates TPR/PPR calculation
 
// Linux wrapper function
void apic_eoi_wrapper(void) {
    if (x2apic_enabled()) {
        wrmsr(MSR_X2APIC_EOI, 0);
    } else {
        *(volatile uint32_t *)(apic_base + APIC_EOI_OFFSET) = 0;
    }
}
 
// Complete APIC interrupt handler example
irqreturn_t apic_irq_handler(int irq, void *dev_id) {
    // 1. Device-specific handling
    process_device_interrupt(dev_id);
    
    // 2. Clear device interrupt condition
    clear_device_interrupt(dev_id);
    
    // 3. Signal EOI to Local APIC
    apic_eoi();
    
    return IRQ_HANDLED;
}

I/O APIC and EOI Broadcasts:

For level-triggered interrupts, the I/O APIC also tracks interrupt delivery state. When using EOI broadcast, the Local APIC sends an EOI message across the system bus to inform the I/O APIC that the interrupt has been handled:

EOI Broadcast Flow (level-triggered):

Handler sends EOI to Local APIC (write to EOI register)
Local APIC clears ISR bit
Local APIC broadcasts EOI message on system bus
I/O APIC receives broadcast for vectors it originated
I/O APIC clears Remote IRR bit, allowing new interrupts

ioapic_level_triggered.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// I/O APIC level-triggered interrupt handling
 
// I/O APIC Redirection Entry - Remote IRR field
struct ioapic_entry {
    // ... other fields ...
    uint8_t remote_irr:1;     // Remote IRR (Interrupt Request Register)
    // For level-triggered: set when delivered, cleared on EOI broadcast
    // ... other fields ...
};
 
// Level-triggered interrupt flow:
//
// 1. Device asserts interrupt line (level goes active)
// 2. I/O APIC sees level, sets IRR bit for that pin
// 3. I/O APIC sends interrupt message to destination LAPIC
// 4. I/O APIC sets Remote IRR bit (prevents re-delivery until EOI)
// 5. Local APIC sets ISR bit, delivers to CPU
// 6. Handler runs, clears device interrupt, writes LAPIC EOI
// 7. LAPIC broadcasts EOI to I/O APIC
// 8. I/O APIC clears Remote IRR
// 9. If device still asserting (new interrupt), repeat from step 2
 
// Directed EOI optimization (suppress broadcast)
// Some systems can send EOI directly to specific I/O APIC
 
#define APIC_SPIV_DIRECTED_EOI  (1 << 12)  // In Spurious Interrupt Vector Register
 
void enable_directed_eoi(void) {
    uint32_t spiv = apic_read(APIC_SPIV);
    spiv |= APIC_SPIV_DIRECTED_EOI;
    apic_write(APIC_SPIV, spiv);
    
    // Now EOI goes only to relevant I/O APIC, reducing bus traffic
}
 
// Edge-triggered is simpler:
// No Remote IRR tracking needed
// EOI goes only to Local APIC, no broadcast
// Device interrupt condition auto-clears on delivery

MSI Simplifies Everything

Message Signaled Interrupts (MSI) are inherently edge-triggered and don't involve the I/O APIC at all. The device writes directly to Main memory (really the Local APIC), and EOI is just the local APIC EOI write—no broadcast needed. This is one reason MSI is preferred for high-performance devices.

Common Acknowledgment Bugs

Interrupt acknowledgment bugs are among the most common and frustrating driver issues. They often manifest as system freezes, lost interrupts, or degraded performance. Let's examine the patterns.

Bug Category 1: The Interrupt Storm

interrupt_storm_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// BUG: Interrupt storm from missing device acknowledgment
 
irqreturn_t broken_handler_storm(int irq, void *dev_id) {
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT))
        return IRQ_NONE;
    
    // Process data
    process_incoming_data();
    
    // BUG: Forgot to clear device interrupt!
    // For level-triggered interrupts, line stays asserted
    // Upon IRET, CPU immediately re-enters this handler
    
    apic_eoi();  // This doesn't help - device still asserting!
    
    return IRQ_HANDLED;
}
 
// Symptoms:
// - CPU usage spikes to 100%
// - /proc/interrupts shows millions of interrupts per second
// - System appears frozen (all time spent in handler)
// - Other devices become unresponsive
 
// Fix: Always clear device interrupt condition
irqreturn_t fixed_handler_storm(int irq, void *dev_id) {
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT))
        return IRQ_NONE;
    
    process_incoming_data();
    
    // CRITICAL: Clear the device interrupt
    iowrite32(OUR_INTERRUPT, dev->interrupt_clear_reg);
    
    // Memory barrier to ensure write completes before EOI
    wmb();
    
    apic_eoi();
    
    return IRQ_HANDLED;
}

Bug Category 2: The Lost Interrupt

lost_interrupt_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// BUG: Lost interrupt from wrong acknowledgment order
 
irqreturn_t broken_handler_lost(int irq, void *dev_id) {
    // Send EOI first (seems reasonable - let other IRQs through)
    apic_eoi();
    
    // Check if this is our interrupt
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT)) {
        // Oops! We already sent EOI for nothing
        return IRQ_NONE;
    }
    
    // BUG: Race condition window exists here
    // 1. We sent EOI before confirming it was our interrupt
    // 2. Another interrupt on this vector can arrive
    // 3. CPU might re-enter handler before we finish
    // 4. State corruption or missed work possible
    
    process_data();
    iowrite32(CLEAR, dev->interrupt_clear_reg);
    
    // Also: If we return IRQ_NONE after EOI, we've lost an interrupt slot
    
    return IRQ_HANDLED;
}
 
// Fix: Verify and acknowledge in proper order
irqreturn_t fixed_handler_lost(int irq, void *dev_id) {
    // First, check if this interrupt is for us
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT)) {
        // NOT our interrupt - don't EOI, don't claim
        return IRQ_NONE;
    }
    
    // Our interrupt - handle it
    process_data();
    
    // Clear device interrupt
    iowrite32(CLEAR, dev->interrupt_clear_reg);
    
    // NOW send EOI (after claiming and clearing)
    apic_eoi();
    
    return IRQ_HANDLED;
}

Bug Category 3: The Double Acknowledgment

double_ack_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// BUG: Double EOI corruption
 
// Handler 1 sends EOI
irqreturn_t handler_irq42(int irq, void *dev_id) {
    handle_device_42();
    clear_device_42_interrupt();
    apic_eoi();  // EOI for vector 42
    return IRQ_HANDLED;
}
 
// If two IRQs are pending simultaneously:
// 1. Vector 42 delivered, handler runs
// 2. Handler sends EOI (clears ISR bit for vector 42)
// 3. Vector 43 was pending, now delivered
// 4. Handler for 43 runs, calls apic_eoi()
// 5. THIS EOI clears ISR bit for vector 43
//
// What if handler_irq42 accidentally calls apic_eoi() twice?
 
irqreturn_t broken_double_eoi(int irq, void *dev_id) {
    handle_device();
    clear_device_interrupt();
    
    apic_eoi();  // First EOI - clears our ISR bit
    
    // Some code path calls this again...
    if (some_condition)
        apic_eoi();  // BUG: Second EOI clears WRONG ISR bit!
    
    // The second EOI clears whatever is now highest in ISR
    // This corrupts interrupt handling for a DIFFERENT device!
    
    return IRQ_HANDLED;
}
 
// Prevention: Linux wraps EOI in architecture-specific code
// that ensures single EOI per handler invocation

Acknowledgment Bug Quick Reference
Bug	Symptom	Cause	Fix
Interrupt Storm	100% CPU, frozen system	Device interrupt not cleared	Clear device status before EOI
Lost Interrupt	Device stops working	EOI sent before claiming	Verify ownership before EOI
Double EOI	Random device failures	EOI called multiple times	Ensure single EOI path
Premature EOI	Race conditions	EOI before stable state	Complete processing, then EOI
Forgotten EOI	Device IRQ blocked	No EOI sent at all	Always EOI on IRQ_HANDLED path

The PCI Write Posting Problem

PCI writes are 'posted'—the CPU continues before the write reaches the device. If you write to clear a device interrupt and immediately send EOI, the EOI might reach the APIC before the clear reaches the device! The device line might still be asserted, causing spurious re-interrupts. Solution: Read back from the device after the clear write to ensure it completed.

The IRQ_HANDLED / IRQ_NONE Protocol

Linux requires interrupt handlers to return a value indicating whether they handled the interrupt. This return value protocol is essential for proper shared IRQ operation and spurious interrupt detection.

Return Values:

irq_return_values.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Linux interrupt handler return values
 
typedef enum irqreturn {
    IRQ_NONE        = 0,  // Interrupt was NOT for this device
    IRQ_HANDLED     = 1,  // Interrupt was handled by this handler
    IRQ_WAKE_THREAD = 2,  // Handler requests threaded handler wake
} irqreturn_t;
 
// The kernel interprets these as follows:
 
// IRQ_NONE:
// - "This interrupt was not for my device"
// - Kernel continues calling other handlers on shared IRQ
// - If ALL handlers return IRQ_NONE: spurious interrupt!
// - 100,000 consecutive unhandled → IRQ disabled (protection)
 
// IRQ_HANDLED:
// - "I successfully processed this interrupt"
// - Kernel may still call other handlers on shared IRQ
// - Resets spurious interrupt counter
 
// IRQ_WAKE_THREAD:
// - "Need to wake my threaded handler"
// - Used with request_threaded_irq()
// - Primary handler did quick work, thread does rest

Shared IRQ Handling Protocol:

When multiple devices share an IRQ line, the kernel calls each registered handler until one returns IRQ_HANDLED. Proper implementation is critical:

shared_irq_protocol.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Correct shared IRQ handler implementation
 
irqreturn_t correct_shared_irq_handler(int irq, void *dev_id) {
    struct my_device *dev = dev_id;
    
    // MUST check if THIS device caused the interrupt
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_PENDING)) {
        // NOT our interrupt - return IRQ_NONE
        // Kernel will try other handlers on this IRQ
        return IRQ_NONE;
    }
    
    // Our interrupt - handle it
    handle_my_device(dev);
    
    // Clear the interrupt condition
    iowrite32(CLEAR_INTERRUPT, dev->status_reg);
    
    // Return IRQ_HANDLED to indicate we processed it
    return IRQ_HANDLED;
}
 
// What the kernel does internally:
irqreturn_t handle_irq_event_percpu(struct irq_desc *desc) {
    irqreturn_t retval = IRQ_NONE;
    struct irqaction *action;
    
    // Call each registered handler
    for_each_handler(action, desc) {
        irqreturn_t res = action->handler(irq, action->dev_id);
        
        if (res == IRQ_HANDLED)
            retval = IRQ_HANDLED;  // At least one handler claimed it
        
        if (res == IRQ_WAKE_THREAD)
            wake_threaded_handler(action);
    }
    
    // If no handler claimed the interrupt...
    if (retval == IRQ_NONE) {
        desc->spurious_count++;
        if (desc->spurious_count > 100000) {
            // Disable this IRQ - it's causing problems
            disable_irq_nosync(irq);
            printk("IRQ %d: nobody cared! Disabling.\n", irq);
        }
    } else {
        desc->spurious_count = 0;
    }
    
    return retval;
}

IRQF_SHARED Requirement

When registering with IRQF_SHARED, the handler MUST check the device's hardware status register and return IRQ_NONE if the device did not generate the interrupt. Handlers that blindly return IRQ_HANDLED on shared lines will mask broken handling by other devices and hide spurious interrupt problems.

Debugging Acknowledgment Issues

When interrupt handling goes wrong, systematic debugging is essential. Here are tools and techniques for diagnosing acknowledgment problems.

Monitoring Interrupt Activity:

interrupt_debugging.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Monitoring interrupt activity in Linux
 
# Watch interrupt counts update in real-time
$ watch -n 0.5 cat /proc/interrupts
 
# Get interrupt rate over time
$ for i in {1..10}; do
    prev=$(cat /proc/interrupts | grep "your_device" | awk '{sum=0; for(i=2;i<=NF;i++) if($i~/^[0-9]+$/) sum+=$i; print sum}')
    sleep 1
    curr=$(cat /proc/interrupts | grep "your_device" | awk '{sum=0; for(i=2;i<=NF;i++) if($i~/^[0-9]+$/) sum+=$i; print sum}')
    echo "IRQ rate: $((curr - prev)) interrupts/second"
done
 
# If you see millions of interrupts per second -> likely interrupt storm
 
# Check for "nobody cared" messages
$ dmesg | grep "nobody cared"
[  123.456789] irq 19: nobody cared (try booting with the "irqpoll" option)
[  123.456790] handlers:
[  123.456791] [<ffffffffa0001234>] my_broken_handler [my_driver]
 
# View IRQ actions and sharing
$ cat /proc/interrupts
           CPU0       CPU1       
 19:       12345          0   IO-APIC  19-fasteoi   device1, device2
# Two devices sharing IRQ 19 - potential for acknowledgment bugs
 
# Check if an IRQ is disabled due to spurious interrupts
$ cat /sys/kernel/irq/19/status
# Flags will include "DISABLED" if killed for spurious
 
# Enable spurious IRQ debugging
$ echo 1 > /sys/kernel/debug/irq/19/spurious_debug

Using ftrace for Interrupt Analysis:

ftrace_irq_debug.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Tracing interrupt handler execution
 
# Enable IRQ tracepoints
$ echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable
$ echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enable
 
# View trace
$ cat /sys/kernel/debug/tracing/trace
# Output shows:
#   irq_handler_entry: irq=25 name=my_device
#   irq_handler_exit: irq=25 ret=handled
#   irq_handler_entry: irq=25 name=my_device  <- STORM if instant repeat
#   ...
 
# Measure handler execution time
$ echo irq:irq_handler_entry irq:irq_handler_exit > /sys/kernel/debug/tracing/set_event
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer
$ cat /sys/kernel/debug/tracing/trace_pipe
 
# Example output with timing:
#  0)               |  my_handler() {
#  0)   2.341 us    |    ioread32();
#  0)   0.523 us    |    process_data();
#  0)   1.234 us    |    iowrite32();  <- Clearing interrupt
#  0) + 12.567 us   |  }
 
# Trace specific functions in handler
$ echo my_driver:my_handler > /sys/kernel/debug/tracing/set_ftrace_filter
$ echo my_driver:clear_interrupt >> /sys/kernel/debug/tracing/set_ftrace_filter

Debugging Checklist for Acknowledgment Issues

•Check interrupt rate: Is it suspiciously high? (>100K/sec unusual)
•Look for 'nobody cared' messages: Indicates no handler claimed the IRQ
•Verify device status register: Is interrupt flag set when handler enters?
•Confirm clear operation works: Read back after clear to verify
•Check for write posting issues: Add read-back after PCI writes
•Examine shared IRQ partners: Other devices on same IRQ may be misbehaving
•Test with IRQ isolation: Temporarily move device to dedicated IRQ
•Enable function tracing: Measure time in handler, look for loops

The 'noapic' Boot Parameter

When debugging interrupt issues, booting with 'noapic' forces use of the legacy PIC, which may have different behavior. This can help isolate whether the problem is APIC-specific or a fundamental driver issue. Also try 'pci=nomsi' to disable MSI and force legacy INTx.

Summary: Interrupt Acknowledgment

We've explored the mechanisms for completing the interrupt cycle. Let's consolidate the key takeaways:

Key Takeaways

•Acknowledgment occurs at two levels — Device acknowledgment clears the hardware interrupt condition; EOI tells the controller the handler is done.
•Device acknowledgment varies by hardware — Read-to-clear, write-to-clear, or explicit acknowledge command. Consult the datasheet.
•PIC EOI requires awareness of cascade — For slave PIC IRQs (8-15), send EOI to both slave and master.
•APIC EOI is simpler but has level-triggered nuances — Level-triggered uses EOI broadcast to I/O APIC to clear Remote IRR.
•Common bugs have common patterns — Interrupt storms (missing device ack), lost interrupts (premature EOI), and double EOI corruption.
•IRQ_HANDLED vs IRQ_NONE is essential for shared IRQs — Handlers MUST check hardware status and return appropriately.
•Debugging requires systematic observation — Use /proc/interrupts, ftrace, and dmesg to understand interrupt behavior.

Module Complete:

With this page, we've completed our deep dive into the Interrupts module. You now understand the complete interrupt lifecycle: from a device asserting an interrupt signal, through the CPU's response and vector table lookup, priority determination, handler execution, and finally acknowledgment. This knowledge is fundamental for operating system development, device driver writing, and systems debugging.

Module Complete

Congratulations! You have mastered the Interrupts module. You understand interrupt-driven I/O, handler implementation and constraints, the interrupt vector table, priority mechanisms, and acknowledgment protocols. These concepts form a cornerstone of operating systems knowledge that will serve you in kernel development, driver writing, embedded systems, and performance analysis.

5 / 5

Loading learning content...

Operating SystemsInterrupts

Interrupts: Hardware-Level I/O Signaling

LevelIntermediate

Duration90 mins

TopicInterrupts

5 / 5

Interrupt Acknowledgment

Completing the Interrupt Cycle

What You Will Learn

Why Acknowledgment is Necessary

The Control Flow:

When an interrupt occurs:

Device asserts interrupt signal
Interrupt controller recognizes and prioritizes
Controller sends interrupt to CPU
CPU saves state and jumps to handler
Handler must acknowledge to both device AND controller
Controller updates its internal state
New interrupts can now be delivered

Without proper acknowledgment, two problems occur:

Missing Device Acknowledgment

•Device keeps interrupt line asserted
•Level-triggered: Interrupt fires again immediately after return
•Creates 'interrupt storm'
•CPU spends 100% time in handler
•System appears frozen
•Other devices cannot be serviced

Missing Controller EOI

•Controller thinks interrupt still pending
•Controller blocks equal/lower priority IRQs
•Subsequent interrupts never delivered
•Devices time out waiting for response
•System becomes progressively unresponsive
•May require hardware reset

Two-Level Acknowledgment:

Proper interrupt acknowledgment involves two distinct operations:

Device Acknowledgment: Tell the device to de-assert its interrupt signal (typically by clearing a status bit or reading a register)
Controller EOI (End of Interrupt): Tell the interrupt controller that the handler is complete and the CPU is ready for the next interrupt

Both must occur, often in a specific order, for correct operation.

Terminology Note

Device-Level Acknowledgment

Each device has its own mechanism for acknowledging interrupts. The driver must understand the device's interrupt behavior and clear the interrupt condition appropriately.

Common Device Acknowledgment Patterns:

device_acknowledgment_patterns.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// Common device acknowledgment patterns
 
// Pattern 1: Write-to-Clear Status Register
// Most common pattern - write 1 to bit to clear it
irqreturn_t write_to_clear_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_BIT))
        return IRQ_NONE;  // Not our interrupt
    
    // Process the interrupt...
    handle_event(status);
    
    // Clear the interrupt by writing 1 to the status bit
    // (Write-1-to-clear is hardware convention for this pattern)
    writel(status & MY_INTERRUPT_BIT, dev->status_reg);
    
    return IRQ_HANDLED;
}
 
// Pattern 2: Read-to-Clear Data Register
// Reading data automatically clears interrupt
irqreturn_t read_to_clear_handler(int irq, void *dev_id) {
    // Simply reading the data register clears the interrupt
    uint32_t data = readl(dev->data_reg);
    
    // The read itself acknowledged the interrupt
    // Now process the data
    process_incoming_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 3: Separate Acknowledge Register
// Explicit acknowledge command to separate register
irqreturn_t explicit_ack_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_BIT))
        return IRQ_NONE;
    
    // Read data while interrupt is pending
    uint32_t data = readl(dev->data_reg);
    
    // Explicit acknowledge command
    writel(ACK_INTERRUPT, dev->interrupt_ack_reg);
    
    // Now process (after ack, new interrupts can queue)
    process_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 4: Auto-Clear on Handler Entry
// Hardware clears interrupt when vector is read
// Common with MSI - no explicit device ack needed
irqreturn_t msi_handler(int irq, void *dev_id) {
    // MSI interrupt is automatically acknowledged when
    // the CPU reads the vector from the interrupt controller
    // No explicit device acknowledgment needed!
    
    uint32_t data = readl(dev->data_reg);
    process_data(data);
    
    return IRQ_HANDLED;
}
 
// Pattern 5: Multiple Interrupt Sources
// Device has multiple interrupt conditions
irqreturn_t multi_source_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->interrupt_status_reg);
    irqreturn_t ret = IRQ_NONE;
    
    if (status & RX_COMPLETE) {
        handle_rx_complete();
        writel(RX_COMPLETE, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    if (status & TX_COMPLETE) {
        handle_tx_complete();
        writel(TX_COMPLETE, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    if (status & ERROR_CONDITION) {
        handle_error();
        writel(ERROR_CONDITION, dev->interrupt_clear_reg);
        ret = IRQ_HANDLED;
    }
    
    // Must clear ALL pending conditions before return
    // or interrupt will re-fire for remaining ones
    return ret;
}

Timing Considerations:

The critical window:

ack_timing.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// CORRECT timing for level-triggered interrupts
irqreturn_t correct_timing_handler(int irq, void *dev_id) {
    // 1. Identify interrupt source
    uint32_t status = readl(dev->status_reg);
    
    // 2. Capture any necessary data
    uint32_t data = readl(dev->data_reg);
    
    // 3. Clear device interrupt BEFORE returning
    writel(CLEAR_INTERRUPT, dev->status_reg);
    
    // 4. Now safe to do lengthy processing
    //    (IRQ line is now de-asserted)
    process_data_extensively(data);
    
    // 5. Return - no interrupt storm because line is clear
    return IRQ_HANDLED;
}
 
// INCORRECT timing - can cause interrupt storm
irqreturn_t incorrect_timing_handler(int irq, void *dev_id) {
    uint32_t status = readl(dev->status_reg);
    uint32_t data = readl(dev->data_reg);
    
    // Do lengthy processing BEFORE clearing interrupt
    process_data_extensively(data);  // Takes 100+ microseconds
    
    // BUG: If we're preempted here, or if this is threaded,
    // interrupt can re-fire before we clear it
    writel(CLEAR_INTERRUPT, dev->status_reg);
    
    return IRQ_HANDLED;
}

Read Your Datasheet

PIC End of Interrupt (EOI)

EOI Types:

8259 PIC EOI Command Types
EOI Type	Command Byte	Usage
Non-Specific EOI	0x20	Clears highest-priority in-service interrupt
Specific EOI	0x60 + IRQ#	Clears specific IRQ (0-7)
Auto EOI Mode	(initialization)	No EOI needed - clears on INTA

pic_eoi.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// 8259 PIC End of Interrupt handling
 
#define PIC1_CMD    0x20    // Master PIC command port
#define PIC2_CMD    0xA0    // Slave PIC command port
#define PIC_EOI     0x20    // Non-specific EOI command
 
// Standard PIC EOI - used by most interrupt handlers
void pic_send_eoi(uint8_t irq) {
    // If IRQ came from slave PIC, send EOI to both
    if (irq >= 8) {
        outb(PIC2_CMD, PIC_EOI);  // EOI to slave
    }
    outb(PIC1_CMD, PIC_EOI);      // EOI to master
}
 
// Why EOI order matters for slave PIC IRQs:
//
// For IRQs 8-15 (slave PIC):
// 1. Master PIC's IRQ2 (cascade) is set in master's ISR
// 2. Slave PIC's corresponding bit is set in slave's ISR
// 3. We must clear BOTH
//
// ORDER: Slave first, then master (or simultaneously)
// If we only EOI master, slave's ISR bit stays set
// -> Future slave IRQs blocked!
 
// Wrapper for interrupt handlers
irqreturn_t pic_irq_handler_wrapper(int irq, void *dev_id,
                                    irqreturn_t (*actual_handler)(int, void*)) {
    irqreturn_t ret = actual_handler(irq, dev_id);
    
    pic_send_eoi(irq);  // Always send EOI
    
    return ret;
}
 
// Example complete PIC interrupt handler
irqreturn_t keyboard_interrupt_handler(int irq, void *dev_id) {
    // 1. Read data from device (may also acknowledge device)
    uint8_t scancode = inb(KEYBOARD_DATA_PORT);
    
    // 2. Process the data
    process_keystroke(scancode);
    
    // 3. Send EOI to PIC
    pic_send_eoi(irq);  // IRQ1 for keyboard
    
    return IRQ_HANDLED;
}
 
// Specific EOI - when you need precise control
void pic_specific_eoi(uint8_t irq) {
    if (irq >= 8) {
        // Specific EOI for slave, then master IRQ2
        outb(PIC2_CMD, 0x60 + (irq - 8));  // Specific EOI to slave
        outb(PIC1_CMD, 0x60 + 2);          // Specific EOI for IRQ2
    } else {
        outb(PIC1_CMD, 0x60 + irq);        // Specific EOI to master
    }
}

When to Send EOI:

The EOI can be sent before or after processing, with different implications:

Early EOI (before processing):

Allows lower-priority interrupts to be delivered during processing
Handler can be preempted by any interrupt
Better for low-latency but requires reentrant handling

Late EOI (after processing):

Blocks lower-priority interrupts until handler completes
Traditional approach for simpler, non-reentrant handlers
Higher interrupt latency for other devices

Auto-EOI Mode

APIC End of Interrupt

APIC EOI Mechanism:

apic_eoi.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// APIC End of Interrupt handling
 
// Local APIC register offsets (memory-mapped)
#define APIC_EOI_OFFSET     0x0B0   // EOI Register
 
// APIC base address (default, can be relocated)
#define APIC_DEFAULT_BASE   0xFEE00000
 
// x2APIC MSR for EOI
#define MSR_X2APIC_EOI      0x80B
 
// Standard APIC EOI (memory-mapped xAPIC)
static inline void apic_eoi(void) {
    // Write any value to EOI register
    // The value is ignored; the write itself triggers EOI
    volatile uint32_t *eoi_reg = (volatile uint32_t *)
        (APIC_DEFAULT_BASE + APIC_EOI_OFFSET);
    *eoi_reg = 0;
}
 
// x2APIC mode EOI (MSR-based, faster)
static inline void x2apic_eoi(void) {
    // Write to MSR is faster than memory-mapped access
    wrmsr(MSR_X2APIC_EOI, 0);
}
 
// What the APIC does on EOI:
// 1. Finds highest-priority bit set in ISR (In-Service Register)
// 2. Clears that bit
// 3. For level-triggered: checks if IRR (Request Register) has same vector
//    If so, re-delivers immediately (device didn't deassert)
// 4. Updates TPR/PPR calculation
 
// Linux wrapper function
void apic_eoi_wrapper(void) {
    if (x2apic_enabled()) {
        wrmsr(MSR_X2APIC_EOI, 0);
    } else {
        *(volatile uint32_t *)(apic_base + APIC_EOI_OFFSET) = 0;
    }
}
 
// Complete APIC interrupt handler example
irqreturn_t apic_irq_handler(int irq, void *dev_id) {
    // 1. Device-specific handling
    process_device_interrupt(dev_id);
    
    // 2. Clear device interrupt condition
    clear_device_interrupt(dev_id);
    
    // 3. Signal EOI to Local APIC
    apic_eoi();
    
    return IRQ_HANDLED;
}

I/O APIC and EOI Broadcasts:

EOI Broadcast Flow (level-triggered):

Handler sends EOI to Local APIC (write to EOI register)
Local APIC clears ISR bit
Local APIC broadcasts EOI message on system bus
I/O APIC receives broadcast for vectors it originated
I/O APIC clears Remote IRR bit, allowing new interrupts

ioapic_level_triggered.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// I/O APIC level-triggered interrupt handling
 
// I/O APIC Redirection Entry - Remote IRR field
struct ioapic_entry {
    // ... other fields ...
    uint8_t remote_irr:1;     // Remote IRR (Interrupt Request Register)
    // For level-triggered: set when delivered, cleared on EOI broadcast
    // ... other fields ...
};
 
// Level-triggered interrupt flow:
//
// 1. Device asserts interrupt line (level goes active)
// 2. I/O APIC sees level, sets IRR bit for that pin
// 3. I/O APIC sends interrupt message to destination LAPIC
// 4. I/O APIC sets Remote IRR bit (prevents re-delivery until EOI)
// 5. Local APIC sets ISR bit, delivers to CPU
// 6. Handler runs, clears device interrupt, writes LAPIC EOI
// 7. LAPIC broadcasts EOI to I/O APIC
// 8. I/O APIC clears Remote IRR
// 9. If device still asserting (new interrupt), repeat from step 2
 
// Directed EOI optimization (suppress broadcast)
// Some systems can send EOI directly to specific I/O APIC
 
#define APIC_SPIV_DIRECTED_EOI  (1 << 12)  // In Spurious Interrupt Vector Register
 
void enable_directed_eoi(void) {
    uint32_t spiv = apic_read(APIC_SPIV);
    spiv |= APIC_SPIV_DIRECTED_EOI;
    apic_write(APIC_SPIV, spiv);
    
    // Now EOI goes only to relevant I/O APIC, reducing bus traffic
}
 
// Edge-triggered is simpler:
// No Remote IRR tracking needed
// EOI goes only to Local APIC, no broadcast
// Device interrupt condition auto-clears on delivery

MSI Simplifies Everything

Common Acknowledgment Bugs

Interrupt acknowledgment bugs are among the most common and frustrating driver issues. They often manifest as system freezes, lost interrupts, or degraded performance. Let's examine the patterns.

Bug Category 1: The Interrupt Storm

interrupt_storm_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// BUG: Interrupt storm from missing device acknowledgment
 
irqreturn_t broken_handler_storm(int irq, void *dev_id) {
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT))
        return IRQ_NONE;
    
    // Process data
    process_incoming_data();
    
    // BUG: Forgot to clear device interrupt!
    // For level-triggered interrupts, line stays asserted
    // Upon IRET, CPU immediately re-enters this handler
    
    apic_eoi();  // This doesn't help - device still asserting!
    
    return IRQ_HANDLED;
}
 
// Symptoms:
// - CPU usage spikes to 100%
// - /proc/interrupts shows millions of interrupts per second
// - System appears frozen (all time spent in handler)
// - Other devices become unresponsive
 
// Fix: Always clear device interrupt condition
irqreturn_t fixed_handler_storm(int irq, void *dev_id) {
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT))
        return IRQ_NONE;
    
    process_incoming_data();
    
    // CRITICAL: Clear the device interrupt
    iowrite32(OUR_INTERRUPT, dev->interrupt_clear_reg);
    
    // Memory barrier to ensure write completes before EOI
    wmb();
    
    apic_eoi();
    
    return IRQ_HANDLED;
}

Bug Category 2: The Lost Interrupt

lost_interrupt_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// BUG: Lost interrupt from wrong acknowledgment order
 
irqreturn_t broken_handler_lost(int irq, void *dev_id) {
    // Send EOI first (seems reasonable - let other IRQs through)
    apic_eoi();
    
    // Check if this is our interrupt
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT)) {
        // Oops! We already sent EOI for nothing
        return IRQ_NONE;
    }
    
    // BUG: Race condition window exists here
    // 1. We sent EOI before confirming it was our interrupt
    // 2. Another interrupt on this vector can arrive
    // 3. CPU might re-enter handler before we finish
    // 4. State corruption or missed work possible
    
    process_data();
    iowrite32(CLEAR, dev->interrupt_clear_reg);
    
    // Also: If we return IRQ_NONE after EOI, we've lost an interrupt slot
    
    return IRQ_HANDLED;
}
 
// Fix: Verify and acknowledge in proper order
irqreturn_t fixed_handler_lost(int irq, void *dev_id) {
    // First, check if this interrupt is for us
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & OUR_INTERRUPT)) {
        // NOT our interrupt - don't EOI, don't claim
        return IRQ_NONE;
    }
    
    // Our interrupt - handle it
    process_data();
    
    // Clear device interrupt
    iowrite32(CLEAR, dev->interrupt_clear_reg);
    
    // NOW send EOI (after claiming and clearing)
    apic_eoi();
    
    return IRQ_HANDLED;
}

Bug Category 3: The Double Acknowledgment

double_ack_bug.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// BUG: Double EOI corruption
 
// Handler 1 sends EOI
irqreturn_t handler_irq42(int irq, void *dev_id) {
    handle_device_42();
    clear_device_42_interrupt();
    apic_eoi();  // EOI for vector 42
    return IRQ_HANDLED;
}
 
// If two IRQs are pending simultaneously:
// 1. Vector 42 delivered, handler runs
// 2. Handler sends EOI (clears ISR bit for vector 42)
// 3. Vector 43 was pending, now delivered
// 4. Handler for 43 runs, calls apic_eoi()
// 5. THIS EOI clears ISR bit for vector 43
//
// What if handler_irq42 accidentally calls apic_eoi() twice?
 
irqreturn_t broken_double_eoi(int irq, void *dev_id) {
    handle_device();
    clear_device_interrupt();
    
    apic_eoi();  // First EOI - clears our ISR bit
    
    // Some code path calls this again...
    if (some_condition)
        apic_eoi();  // BUG: Second EOI clears WRONG ISR bit!
    
    // The second EOI clears whatever is now highest in ISR
    // This corrupts interrupt handling for a DIFFERENT device!
    
    return IRQ_HANDLED;
}
 
// Prevention: Linux wraps EOI in architecture-specific code
// that ensures single EOI per handler invocation

Acknowledgment Bug Quick Reference
Bug	Symptom	Cause	Fix
Interrupt Storm	100% CPU, frozen system	Device interrupt not cleared	Clear device status before EOI
Lost Interrupt	Device stops working	EOI sent before claiming	Verify ownership before EOI
Double EOI	Random device failures	EOI called multiple times	Ensure single EOI path
Premature EOI	Race conditions	EOI before stable state	Complete processing, then EOI
Forgotten EOI	Device IRQ blocked	No EOI sent at all	Always EOI on IRQ_HANDLED path

The PCI Write Posting Problem

The IRQ_HANDLED / IRQ_NONE Protocol

Return Values:

irq_return_values.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Linux interrupt handler return values
 
typedef enum irqreturn {
    IRQ_NONE        = 0,  // Interrupt was NOT for this device
    IRQ_HANDLED     = 1,  // Interrupt was handled by this handler
    IRQ_WAKE_THREAD = 2,  // Handler requests threaded handler wake
} irqreturn_t;
 
// The kernel interprets these as follows:
 
// IRQ_NONE:
// - "This interrupt was not for my device"
// - Kernel continues calling other handlers on shared IRQ
// - If ALL handlers return IRQ_NONE: spurious interrupt!
// - 100,000 consecutive unhandled → IRQ disabled (protection)
 
// IRQ_HANDLED:
// - "I successfully processed this interrupt"
// - Kernel may still call other handlers on shared IRQ
// - Resets spurious interrupt counter
 
// IRQ_WAKE_THREAD:
// - "Need to wake my threaded handler"
// - Used with request_threaded_irq()
// - Primary handler did quick work, thread does rest

Shared IRQ Handling Protocol:

When multiple devices share an IRQ line, the kernel calls each registered handler until one returns IRQ_HANDLED. Proper implementation is critical:

shared_irq_protocol.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Correct shared IRQ handler implementation
 
irqreturn_t correct_shared_irq_handler(int irq, void *dev_id) {
    struct my_device *dev = dev_id;
    
    // MUST check if THIS device caused the interrupt
    uint32_t status = ioread32(dev->status_reg);
    
    if (!(status & MY_INTERRUPT_PENDING)) {
        // NOT our interrupt - return IRQ_NONE
        // Kernel will try other handlers on this IRQ
        return IRQ_NONE;
    }
    
    // Our interrupt - handle it
    handle_my_device(dev);
    
    // Clear the interrupt condition
    iowrite32(CLEAR_INTERRUPT, dev->status_reg);
    
    // Return IRQ_HANDLED to indicate we processed it
    return IRQ_HANDLED;
}
 
// What the kernel does internally:
irqreturn_t handle_irq_event_percpu(struct irq_desc *desc) {
    irqreturn_t retval = IRQ_NONE;
    struct irqaction *action;
    
    // Call each registered handler
    for_each_handler(action, desc) {
        irqreturn_t res = action->handler(irq, action->dev_id);
        
        if (res == IRQ_HANDLED)
            retval = IRQ_HANDLED;  // At least one handler claimed it
        
        if (res == IRQ_WAKE_THREAD)
            wake_threaded_handler(action);
    }
    
    // If no handler claimed the interrupt...
    if (retval == IRQ_NONE) {
        desc->spurious_count++;
        if (desc->spurious_count > 100000) {
            // Disable this IRQ - it's causing problems
            disable_irq_nosync(irq);
            printk("IRQ %d: nobody cared! Disabling.\n", irq);
        }
    } else {
        desc->spurious_count = 0;
    }
    
    return retval;
}

IRQF_SHARED Requirement

Debugging Acknowledgment Issues

When interrupt handling goes wrong, systematic debugging is essential. Here are tools and techniques for diagnosing acknowledgment problems.

Monitoring Interrupt Activity:

interrupt_debugging.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Monitoring interrupt activity in Linux
 
# Watch interrupt counts update in real-time
$ watch -n 0.5 cat /proc/interrupts
 
# Get interrupt rate over time
$ for i in {1..10}; do
    prev=$(cat /proc/interrupts | grep "your_device" | awk '{sum=0; for(i=2;i<=NF;i++) if($i~/^[0-9]+$/) sum+=$i; print sum}')
    sleep 1
    curr=$(cat /proc/interrupts | grep "your_device" | awk '{sum=0; for(i=2;i<=NF;i++) if($i~/^[0-9]+$/) sum+=$i; print sum}')
    echo "IRQ rate: $((curr - prev)) interrupts/second"
done
 
# If you see millions of interrupts per second -> likely interrupt storm
 
# Check for "nobody cared" messages
$ dmesg | grep "nobody cared"
[  123.456789] irq 19: nobody cared (try booting with the "irqpoll" option)
[  123.456790] handlers:
[  123.456791] [<ffffffffa0001234>] my_broken_handler [my_driver]
 
# View IRQ actions and sharing
$ cat /proc/interrupts
           CPU0       CPU1       
 19:       12345          0   IO-APIC  19-fasteoi   device1, device2
# Two devices sharing IRQ 19 - potential for acknowledgment bugs
 
# Check if an IRQ is disabled due to spurious interrupts
$ cat /sys/kernel/irq/19/status
# Flags will include "DISABLED" if killed for spurious
 
# Enable spurious IRQ debugging
$ echo 1 > /sys/kernel/debug/irq/19/spurious_debug

Using ftrace for Interrupt Analysis:

ftrace_irq_debug.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Tracing interrupt handler execution
 
# Enable IRQ tracepoints
$ echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable
$ echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enable
 
# View trace
$ cat /sys/kernel/debug/tracing/trace
# Output shows:
#   irq_handler_entry: irq=25 name=my_device
#   irq_handler_exit: irq=25 ret=handled
#   irq_handler_entry: irq=25 name=my_device  <- STORM if instant repeat
#   ...
 
# Measure handler execution time
$ echo irq:irq_handler_entry irq:irq_handler_exit > /sys/kernel/debug/tracing/set_event
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer
$ cat /sys/kernel/debug/tracing/trace_pipe
 
# Example output with timing:
#  0)               |  my_handler() {
#  0)   2.341 us    |    ioread32();
#  0)   0.523 us    |    process_data();
#  0)   1.234 us    |    iowrite32();  <- Clearing interrupt
#  0) + 12.567 us   |  }
 
# Trace specific functions in handler
$ echo my_driver:my_handler > /sys/kernel/debug/tracing/set_ftrace_filter
$ echo my_driver:clear_interrupt >> /sys/kernel/debug/tracing/set_ftrace_filter

Debugging Checklist for Acknowledgment Issues

•Check interrupt rate: Is it suspiciously high? (>100K/sec unusual)
•Look for 'nobody cared' messages: Indicates no handler claimed the IRQ
•Verify device status register: Is interrupt flag set when handler enters?
•Confirm clear operation works: Read back after clear to verify
•Check for write posting issues: Add read-back after PCI writes
•Examine shared IRQ partners: Other devices on same IRQ may be misbehaving
•Test with IRQ isolation: Temporarily move device to dedicated IRQ
•Enable function tracing: Measure time in handler, look for loops

The 'noapic' Boot Parameter

Summary: Interrupt Acknowledgment

We've explored the mechanisms for completing the interrupt cycle. Let's consolidate the key takeaways:

Key Takeaways

•Acknowledgment occurs at two levels — Device acknowledgment clears the hardware interrupt condition; EOI tells the controller the handler is done.
•Device acknowledgment varies by hardware — Read-to-clear, write-to-clear, or explicit acknowledge command. Consult the datasheet.
•PIC EOI requires awareness of cascade — For slave PIC IRQs (8-15), send EOI to both slave and master.
•APIC EOI is simpler but has level-triggered nuances — Level-triggered uses EOI broadcast to I/O APIC to clear Remote IRR.
•Common bugs have common patterns — Interrupt storms (missing device ack), lost interrupts (premature EOI), and double EOI corruption.
•IRQ_HANDLED vs IRQ_NONE is essential for shared IRQs — Handlers MUST check hardware status and return appropriately.
•Debugging requires systematic observation — Use /proc/interrupts, ftrace, and dmesg to understand interrupt behavior.

Module Complete:

Module Complete

5 / 5