Understanding kernel message 'nobody cared (try booting with the "irqpoll" option)'

Question

I'm trying to understand the meaning of the following message:

irq N:nobody cared (try booting with the "irqpoll" option)

Does this mean the IRQ handler not processing the response even it has gotten the interrupt? Or that the scheduler failed to call an irq handler?

In what condition is this happening?

Michele

Answer 1

it means that either no handler is registered for that irq or the one that is returned status indicating that the irq was not for him (from hardware he is supporting) in case of shared interrupts probably a faulty HW/FW or buggy driver

Redfish

Answer 2

Ideally, the above message should be followed by a stack trace, which should help you determine which subsystem is causing the issue. This message means the interrupt handler got stuck due to a overhead, and did not return thus causing the system to disable IRQ#X. This is seen in cases of a buggy firmware.

The irqpoll option needs to be added to grub.conf, which means, when an interrupt is not handled, search all known interrupt handlers for the appropriate handlers and also check all handlers on each timer interrupt. This is sometimes useful to get systems with broken firmware running. The kernel command line in grub.conf should look like the following:

kernel /vmlinuz-version ro root=/dev/sda1 quiet irqpoll

Hereunto

Negative: The hardware that caused the interrupt, did NOT get its handler called, so that driver is the one thing that is NOT running..... – Absolve

Answer 3

Minimal runnable QEMU example

QEMU has an educational device called edu that generates interrupts, and is perfect to explore this.

First, I have created a minimal Linux PCI device driver for it, which handles the interrupt correctly.

Now we can easily generate the error by commenting out request_irq and free_irq from the code.

Then, if we run the userland program that generates IRQs, we get:

irq 11: nobody cared (try booting with the "irqpoll" option)

followed by a stack trace.

So as others mentioned: unhandled IRQs.

Potage

Answer 4

In my case after reloading the driver because the network card had billions of errors in a short period of time.

modprobe -r ixgbe && modprobe ixgbe 

lspci showed an unknown device where the 'card' used to be

after a reboot the card disappeared never to be seen again.

So the error might also show failing hardware.

Oversold

Answer 5

I've got the same message after BIOS upgrade on a Lenovo m625q thin client.

irqpoll did fix the error but I didn't like the solution. Also I didn't want to downgrade firmware because of laziness. Which caused me more work at the end..

The error I had in dmesg pointed at the sound card.

I found that spoofing OS made things work without error. acpi_osi=! acpi_osi='Windows 2013'

I first tried Windows 2015 which corresponds to windows 10 initial edition. (2013 is windows 8.1, ref linux sources), but it failed to boot completely.

To see available options for your particular firmware use

(cd /tmp && mkdir acpi && cd acpi && sudo acpidump -b && for i in *; do echo $i:; strings -a $i | grep -i windows; done)

Credit to the excellent answer: https://unix.stackexchange.com/a/609989/14907

I think it is worth trying instead or resorting to the irqpoll which may or may not have measurable performance impact. I guess depends on the failing device/driver and it's usage.

Bilestone

Answer 6

see here:

static inline int bad_action_ret(irqreturn_t action_ret)
{
    if (likely(action_ret <= (IRQ_HANDLED | IRQ_WAKE_THREAD)))
        return 0;
    return 1;
}

Danella

can you add some explanation? – Touristy

static void poll_spurious_irqs(unsigned long dummy) { struct irq_desc *desc; int i; } – Danella

100000 interrupt if more than 99000, then the timer will start the continuous polling – Danella

This post needs context. Nothing here makes any sense in isolation. – Howey