Disabling IRQ #10 and #169

[Blue Beret]

My system works fine, but this thing keeps me annoyed. It seems to happen every hour or so, that all my terminals receive messages about Disabling IRQ #10 and Disabling IRQ #169. If I work on tty1, it also shows a nice debug message. However, there appears to be no problem with these IRQ's (UPDATE: USB devices stop working after IRQ #10 gets disabled), it's only the messages that keep disturbing my work. I'd like to have this fixed - a secondary solution would be just to disable these messages, but I haven't managed to do even this.
Enough talking, here are some facts you might need:

Kernel version

Linux ramusmaker 2.6.17-1-686 #1 SMP Thu Jul 13 14:30:26 UTC 2006 i686 GNU/Linux

(however, this behavior showed on 2.6.15 and 2.6.16 kernels as well)

/proc/interrupts

           CPU0       
  0:     513784    IO-APIC-edge  timer
  1:      10054    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
 10:      29058   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2
 11:      65797   IO-APIC-level  acpi, VIA686A
 12:      29150    IO-APIC-edge  i8042
 14:      17597    IO-APIC-edge  ide0
 15:        683    IO-APIC-edge  ide1
169:     237378   IO-APIC-level  eth0
177:     160859   IO-APIC-level  nvidia
NMI:          0 
LOC:     513744 
ERR:          0
MIS:          0

some information from syslog

Jul 13 11:39:06 localhost kernel: irq 169: nobody cared (try booting with the "irqpoll" option)
Jul 13 11:39:06 localhost kernel:  [<b012f12f>] __report_bad_irq+0x2b/0x69
Jul 13 11:39:06 localhost kernel:  [<b012f2e3>] note_interrupt+0x176/0x1a7
Jul 13 11:39:06 localhost kernel:  [<b012ed4b>] handle_IRQ_event+0x20/0x4c
Jul 13 11:39:06 localhost kernel:  [<b012eddc>] __do_IRQ+0x65/0x91
Jul 13 11:39:06 localhost kernel:  [<b0104a1b>] do_IRQ+0x1d/0x2a
Jul 13 11:39:06 localhost kernel:  [<b010335a>] common_interrupt+0x1a/0x20
Jul 13 11:39:06 localhost kernel:  [<c0ce5cd4>] snd_pcm_period_elapsed+0x1a9/0x1d7 [snd_pcm]
Jul 13 11:39:06 localhost kernel:  [<c0d88768>] snd_via686_interrupt+0x7c/0x9a [snd_via82xx]
Jul 13 11:39:06 localhost kernel:  [<b012ed4b>] handle_IRQ_event+0x20/0x4c
Jul 13 11:39:06 localhost kernel:  [<b012edca>] __do_IRQ+0x53/0x91
Jul 13 11:39:06 localhost kernel:  [<b0104a1b>] do_IRQ+0x1d/0x2a
Jul 13 11:39:06 localhost kernel:  [<b010335a>] common_interrupt+0x1a/0x20
Jul 13 11:39:06 localhost kernel:  [<b01019b1>] default_idle+0x2b/0x53
Jul 13 11:39:06 localhost kernel:  [<b0101a18>] cpu_idle+0x3f/0x57
Jul 13 11:39:06 localhost kernel:  [<b02e842d>] start_kernel+0x291/0x293
Jul 13 11:39:06 localhost kernel: handlers:
Jul 13 11:39:06 localhost kernel: [<c0c8fa5e>] (ei_interrupt+0x0/0x27e [8390])
Jul 13 11:39:06 localhost kernel: Disabling IRQ #169
Jul 13 11:39:16 localhost kernel: irq 10: nobody cared (try booting with the "irqpoll" option)
Jul 13 11:39:16 localhost kernel:  [<b012f12f>] __report_bad_irq+0x2b/0x69
Jul 13 11:39:16 localhost kernel:  [<b012f2e3>] note_interrupt+0x176/0x1a7
Jul 13 11:39:16 localhost kernel:  [<b012ed4b>] handle_IRQ_event+0x20/0x4c
Jul 13 11:39:16 localhost kernel:  [<b012eddc>] __do_IRQ+0x65/0x91
Jul 13 11:39:16 localhost kernel:  [<b0104a1b>] do_IRQ+0x1d/0x2a
Jul 13 11:39:16 localhost kernel:  [<b010335a>] common_interrupt+0x1a/0x20
Jul 13 11:39:16 localhost kernel: handlers:
Jul 13 11:39:16 localhost kernel: [<c0d66b5b>] (usb_hcd_irq+0x0/0x54 [usbcore])
Jul 13 11:39:16 localhost kernel: [<c0d66b5b>] (usb_hcd_irq+0x0/0x54 [usbcore])
Jul 13 11:39:16 localhost kernel: Disabling IRQ #10
Jul 13 11:50:25 localhost kernel: irq 169: nobody cared (try booting with the "irqpoll" option)
Jul 13 11:50:25 localhost kernel:  [<b012f12f>] __report_bad_irq+0x2b/0x69
Jul 13 11:50:25 localhost kernel:  [<b012f2e3>] note_interrupt+0x176/0x1a7
Jul 13 11:50:25 localhost kernel:  [<b012ed4b>] handle_IRQ_event+0x20/0x4c
Jul 13 11:50:25 localhost kernel:  [<b012eddc>] __do_IRQ+0x65/0x91
Jul 13 11:50:25 localhost kernel:  [<b0104a1b>] do_IRQ+0x1d/0x2a
Jul 13 11:50:25 localhost kernel:  [<b010335a>] common_interrupt+0x1a/0x20
Jul 13 11:50:25 localhost kernel:  [<b012ed48>] handle_IRQ_event+0x1d/0x4c
Jul 13 11:50:25 localhost kernel:  [<b012edca>] __do_IRQ+0x53/0x91
Jul 13 11:50:25 localhost kernel:  [<b0104a1b>] do_IRQ+0x1d/0x2a
Jul 13 11:50:25 localhost kernel:  [<b010335a>] common_interrupt+0x1a/0x20
Jul 13 11:50:25 localhost kernel: handlers:
Jul 13 11:50:25 localhost kernel: [<c0c8fa5e>] (ei_interrupt+0x0/0x27e [8390])
Jul 13 11:50:25 localhost kernel: Disabling IRQ #169

Note 1: Sometimes one message is generated twice. Nevertheless, nothing else seems to happen.
Note 2: I tried "booting with the irqpoll option" as the kernel told me: the messages appeared as usual, with the only difference that the system froze completely for about 10 seconds before the messages were sent.

Last, some timestamps to let you know how often this happens (my system doesn't run permanently, only a few hours a day)

Jul 10 09:30:23 localhost kernel: Disabling IRQ #10
Jul 10 10:26:17 localhost kernel: Disabling IRQ #169
Jul 10 11:12:36 localhost kernel: Disabling IRQ #169
Jul 10 13:50:07 localhost kernel: Disabling IRQ #169
Jul 11 12:37:36 localhost kernel: Disabling IRQ #169
Jul 11 13:29:48 localhost kernel: Disabling IRQ #169
Jul 12 12:26:01 localhost kernel: Disabling IRQ #169
Jul 12 12:26:13 localhost kernel: Disabling IRQ #10
Jul 12 13:40:08 localhost kernel: Disabling IRQ #169
Jul 13 11:39:06 localhost kernel: Disabling IRQ #169
Jul 13 11:39:16 localhost kernel: Disabling IRQ #10
Jul 13 11:50:25 localhost kernel: Disabling IRQ #169
Jul 13 12:31:23 localhost kernel: Disabling IRQ #169
Jul 13 13:07:47 localhost kernel: Disabling IRQ #169
Jul 13 14:38:50 localhost kernel: Disabling IRQ #169
Jul 13 14:39:17 localhost kernel: Disabling IRQ #10

I hope that I've provided enough information to let someone help me with this problem.

[bardland]

I don't know if we have anything like the same setup, but I noticed that my IRQ 10 only went disabled when I was playing music in the background.
My motherboard has an on-board soundcard, and a soundblaster card as well. I've tried disabling the onboard soundcard in bios, but that never worked for me. So there were lots and lots of modules referring to via82xx loaded. (lsmod | grep via82xx gave me bunch of stuff)

To check if you have anything like the same setup like me you can try something like:

# lspci | grep audio
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 04)

Here's what I did to fix the problem:
1. I commented out all references to "snd-via82xx" in all files in /etc/modutils by putting "#" marks in front of the lines. As far as I know, the files in /etc/modultils/ are used to automagically (using the update-modules command) populate the /etc/modules.conf file, so it's probably better to etit these files than the modules.conf directly.
Here's how my files looked after the commenting out:

grep via82xx *
alsa-base:#above snd-via82xx snd-seq
alsa-base:#options snd-via82xx-modem index=-2
alsa-base-blacklist:# alias snd-via82xx-modem off
sound:#alias snd-card-0 snd-via82xx
sound:#options snd-via82xx index=0

Then i ran the "modules-update" script (which I think is debian-specific) and rebooted.

Earlier, I got the "Disabling IRQ #10" as soon as I tried to listen to music, but now it's gone.

On a side note; in my setup, the mouse pointer started behaving jerkily when that IRQ got disabled, probably because the irq #10 is the usb irq, and I have a usb mouse.

As I stated earlier, I have no idea if your setup resembles mine, and when googling around the web I found lots of ideas, but none of the sources I looked at said anything about sound. The weird thing is that as far as I could tell, the mouse was the only thing that stopped working, but hey, I'm kinda fond of my mouse. :)

Hope this helps someone!

[Blue Beret]

So this is what I got from the lspci...

00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)

I don't think my problem is related to the soundboard in any way. The events occur both with and without music in background.
When IRQ 10 gets disabled, udev stops recognizing any new USB devices until I restart the uhci_hcd module. When IRQ 169 gets disabled, nothing seems to happen with the network.
The strage thing is that they get disabled repeatedly. One would think they need to be re-enabled to be disabled again, don't they?

[Blue Beret]

Well, did I say nothing happens with the network interface? Here is some log, I got this at random:

Oct  1 11:45:35 localhost kernel: irq 169: nobody cared (try booting with the "irqpoll" option)
Oct  1 11:45:35 localhost kernel:  [<c013e803>] __report_bad_irq+0x2b/0x69
Oct  1 11:45:35 localhost kernel:  [<c013e9f0>] note_interrupt+0x1af/0x1e7
Oct  1 11:45:35 localhost kernel:  [<c013e007>] handle_IRQ_event+0x23/0x49
Oct  1 11:45:35 localhost kernel:  [<c013e0e0>] __do_IRQ+0xb3/0xe8
Oct  1 11:45:35 localhost kernel:  [<c01050e5>] do_IRQ+0x43/0x52
Oct  1 11:45:35 localhost kernel:  [<c01036b6>] common_interrupt+0x1a/0x20
Oct  1 11:45:35 localhost kernel:  [<d153007b>] _nv002527rm+0x4b/0x158 [nvidia]
Oct  1 11:45:35 localhost kernel:  [<c01d3f62>] acpi_os_read_port+0x28/0x42
Oct  1 11:45:35 localhost kernel:  [<c01e02d0>] acpi_hw_register_read+0x88/0x177
Oct  1 11:45:35 localhost kernel:  [<c01d8137>] acpi_ev_fixed_event_detect+0x2b/0xab
Oct  1 11:45:35 localhost kernel:  [<d0d2c759>] ei_interrupt+0x39/0x284 [8390]
Oct  1 11:45:35 localhost kernel:  [<c01d8a0d>] acpi_ev_sci_xrupt_handler+0x9/0x19
Oct  1 11:45:35 localhost kernel:  [<c01d3f31>] acpi_irq+0xb/0x14
Oct  1 11:45:35 localhost kernel:  [<c013e007>] handle_IRQ_event+0x23/0x49
Oct  1 11:45:35 localhost kernel:  [<c013e0c0>] __do_IRQ+0x93/0xe8
Oct  1 11:45:35 localhost kernel:  [<c01050e5>] do_IRQ+0x43/0x52
Oct  1 11:45:35 localhost kernel:  [<c01036b6>] common_interrupt+0x1a/0x20
Oct  1 11:45:35 localhost kernel: handlers:
Oct  1 11:45:35 localhost kernel: [<d0d2c720>] (ei_interrupt+0x0/0x284 [8390])
Oct  1 11:45:35 localhost kernel: Disabling IRQ #169
Oct  1 11:46:00 localhost kernel: irq 10: nobody cared (try booting with the "irqpoll" option)
Oct  1 11:46:00 localhost kernel:  [<c013e803>] __report_bad_irq+0x2b/0x69
Oct  1 11:46:00 localhost kernel:  [<c013e9f0>] note_interrupt+0x1af/0x1e7
Oct  1 11:46:00 localhost kernel:  [<d0cbd49f>] usb_hcd_irq+0x23/0x50 [usbcore]
Oct  1 11:46:00 localhost kernel:  [<c013e007>] handle_IRQ_event+0x23/0x49
Oct  1 11:46:00 localhost kernel:  [<c013e0e0>] __do_IRQ+0xb3/0xe8
Oct  1 11:46:00 localhost kernel:  [<c01050e5>] do_IRQ+0x43/0x52
Oct  1 11:46:00 localhost kernel:  [<c01036b6>] common_interrupt+0x1a/0x20
Oct  1 11:46:00 localhost kernel: handlers:
Oct  1 11:46:00 localhost kernel: [<d0cbd47c>] (usb_hcd_irq+0x0/0x50 [usbcore])
Oct  1 11:46:00 localhost kernel: [<d0cbd47c>] (usb_hcd_irq+0x0/0x50 [usbcore])
Oct  1 11:46:00 localhost kernel: Disabling IRQ #10
Oct  1 11:46:26 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:26 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=99.
Oct  1 11:46:26 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:26 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=98.
Oct  1 11:46:27 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:27 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=78.
Oct  1 11:46:28 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:28 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=61.
Oct  1 11:46:30 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:30 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=388.
Oct  1 11:46:31 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:31 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=240.
Oct  1 11:46:32 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:32 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=59.
Oct  1 11:46:37 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:37 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=295.
Oct  1 11:46:39 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:39 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=445.
Oct  1 11:46:41 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:41 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=298.
Oct  1 11:46:47 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:47 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=257.
Oct  1 11:46:53 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:53 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1257.
Oct  1 11:46:55 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct  1 11:46:55 localhost kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=278.
...
etc.

[Blue Beret]

So: I went once again around the World Wide Web to find out a workaround for this: the 'noirqdebug' kernel option. For me, it works. It isn't meant to do the right job at all cases like this, but it's at least worth trying.
Next, from the number of 'nobody cared' problems I found on Google, I guess somebody should write an article about these messages, what they mean, why they appear and possibly how to deal with them. I don't know anything about this, I'm just glad I get no more beeps and garbage in my terminals (although I know it is not the ideal solution and I should have sent a bug report to someone instead). Thread closed

[SupermanInNY]

This is a very old thread, yet I've encountered the same problem 4 years later.

I have an ASUS p5kpl-cm motherboard and linux CentOS 5.5 gave those same errors.

I tried d/g to 5.3, but to no avail.

I disabled the USB in the BIOS, and that cleared the errors when booting.
But, of course this is not the desired outcome.



The resolve:

Update to the BIOS to latest BIOS version fixed the issue.

No more errors on boot.

While this is an old issue, it still applied to me.

HTH someone else.

-Sup.