PRANAB NANDY

How Changing from IRQ_HANDLED to IRQ_NONE Solves the Problem?

Shared Interrupts (IRQF_SHARED)

When you register multiple handlers for the same IRQ with IRQF_SHARED, the kernel:

1. Calls ALL registered handlers when an interrupt fires
2. If ANY handler returns IRQ_HANDLED, assumes the interrupt was handled
3. If ALL handlers return IRQ_NONE, assumes no one handled the interrupt

The Problem with IRQ_HANDLED

During VM restart:

1. Interrupt line is stuck at hardware level
2. Interrupt status register shows 0x0 (no pending interrupts)
3. Handler returns IRQ_HANDLED (always!)
4. Kernel thinks interrupt was handled
5. But interrupt line is still stuck, fires again immediately
6. Infinite loop → Interrupt storm → System crash

The Solution with IRQ_NONE

During VM restart:

1. Interrupt line is stuck at hardware level
2. Interrupt status register shows 0x0
3. Handler returns IRQ_NONE (no interrupt to handle)
4. Kernel sees no handler handled the interrupt
5. Kernel disables the interrupt ("Disabling IRQ #34")
6. System continues booting

It's the kernel protecting the system from interrupt storms when the interrupt line is stuck at hardware level.

Returning IRQ_NONE when there's no interrupt to handle is the correct behaviour for shared interrupts.

Hi,

I am Pranab Nandy. Qualcomm Id - 186538

I have issue with my qualcomm PF passbook.