kernel: Disabling IRQ #19

shogun1234 · 11-21-2008, 09:01 AM

I use laptop HP 6910p and lately install Debian etch (then upgrading to lenny) with kernel 2.6.24-etchnhalf.1-686-bigmem.

However, I usually obtain a message ` kernel: Disabling IRQ #19' in the terminal. When looking up the /var/log/message

It says

Code:

Nov 21 22:40:40 kernel: Pid: 0, comm: swapper Tainted: P        2.6.24-etchnhalf.1-686-bigmem #1
[<c01590b2>] __report_bad_irq+0x36/0x75
[<c01592cc>] note_interrupt+0x1db/0x217
[<c013c428>] getnstimeofday+0x30/0xb8
[<c01587d3>] handle_IRQ_event+0x23/0x51
[<c0159a47>] handle_fasteoi_irq+0x86/0xa6
[<c0106701>] do_IRQ+0x55/0x70
[<c01048cb>] common_interrupt+0x23/0x28
[<c012007b>] __enqueue_entity+0x70/0xa1
[<f884d448>] acpi_idle_enter_bm+0x27f/0x2ed [processor]
[<c02549cc>] cpuidle_idle_call+0x5c/0x80
[<c0254970>] cpuidle_idle_call+0x0/0x80
[<c01025f8>] cpu_idle+0xab/0xcc
[<c037d93f>] start_kernel+0x336/0x33e
[<c037d0e0>] unknown_bootoption+0x0/0x195

What does this mean? Is this a serious problem? How to solve it?

Thanks for help.

sundialsvcs · 11-21-2008, 10:29 AM

When you see a message like this one, it is not appropriate to assume that it is in fact an error. It probably isn't.

"Use the source, Luke!" To find an explanation for your question, I did:
grep -rilw "disabling IRQ #"/usr/src/linux/*

This took me to kernel/irq/spurious.c Not too much in the way of explanation there, although this is where that message came from. The author said:

Quote:

* If 99,900 of the previous 100,000 interrupts have not been handled
* then assume that the IRQ is stuck in some manner. Drop a diagnostic
* and try to turn the IRQ off.
*
* (The other 100-of-100,000 interrupts may have been a correctly
* functioning device sharing an IRQ with the failing one)

Not so helpful to me.

So, I used the same grep technique to look for the word "spurious" in the Documentation subfolder.

In Documentation/filesystems/proc.txt I find the following paragraph:

Quote:

... a spurious interrupt is some interrupt that was raised then lowered by some IO device before it could be fully processed by the APIC. Hence the APIC sees the interrupt but does not know what device it came from. For this case the APIC will generate the interrupt with a IRQ vector of 0xff. This might also be generated by chipset bugs.

If you know your system well, find out what device(s) are sitting on IRQ #19. It is most likely to be a network card. In that case, perhaps your system is using the wrong or an inappropriate driver for that card.

Each interrupt-handler is supposed to do whatever is necessary to shut off that interrupt after handling it, and what you have here (from the kernel's point of view) is "a phone that just don't stop ringin'."