# IRQ 10 Disabled? Freezes mouse and causes system crash later

## ArloWhite

Fairly often my mouse will freeze.  If I switch to a VT, reset the X-server, or just log-out of the session, the whole system will freeze, requiring a hard reboot.  I have the output from dmesg bellow, where you can see that irq 10 is disabled by the kernel, causing the mouse problem.  The relevent line frome /proc/interrupts is there, showing that irq 10 is connected with usb.  (The mouse I'm using is usb)

I believe this problem has started with the 2.6 series, but I don't remember it being this prevelent before.  It may have been introduced by 2.6.4.  I was previously using mm-sources, then gdev-sources, now I'm using regular developement-sources in order to try to isolate the problem.  I may have to go back to 2.4 soon.

Could someone give me some insight into these errors?  What does "nobody cared!" actually mean?

Thanks,

Arlo

linux-2.6.4 vanilla

SMP Dual PIII 1ghz Coppermine

Radeon 8500 (ati-drivers)

Xfree-4.3.0-r5

From /proc/interrupts:

 10:       5842          1   IO-APIC-level  uhci_hcd, uhci_hcd

```
irq 10: nobody cared!

Call Trace:

 [<c010baca>] __report_bad_irq+0x2a/0x90

 [<c010bbc0>] note_interrupt+0x70/0xb0

 [<c010bf00>] do_IRQ+0x160/0x1a0

 [<c0105000>] _stext+0x0/0x60

 [<c0109fd8>] common_interrupt+0x18/0x20

 [<c0107030>] default_idle+0x0/0x40

 [<c0105000>] _stext+0x0/0x60

 [<c010705c>] default_idle+0x2c/0x40

 [<c01070eb>] cpu_idle+0x3b/0x50

 [<c04e08f7>] start_kernel+0x187/0x1c0

 [<c04e04a0>] unknown_bootoption+0x0/0x120

handlers:

[<c02e8540>] (usb_hcd_irq+0x0/0x70)

[<c02e8540>] (usb_hcd_irq+0x0/0x70)

Disabling IRQ #10

```

----------

## willkil

I am having exactly the same problem. My mouse is an usb intellimouse and I also have gpm running. However, I did not have the problem at all when I was using a gdev-2.6.0-r1 kernel, and gpm was running then too.

I think "nobody cared" simply means none of the IRQ 11 handlers handled the interrupt. I compile almost everything as modules. I'm guessing you compiled usbcore directly into the kernel to account for the difference between our logs.

Anyway, it's not general to 2.6 because I didn't have problems with 2.6.0. I'm going to try vanilla 2.6.5 next and if that has problems go backwards through 2.6.3-2.6.1 to try to isolate when this apparent kernel bug appeared.

Cheers,

William

gentoo-dev-2.6.4-r1

MS Intellimouse USB

Athlon XP 1500

Xfree-4.3.0-r5

KDE-3.2.1

```
Apr  6 15:33:00 phantom kernel: irq 11: nobody cared!

Apr  6 15:33:00 phantom kernel: Call Trace:

Apr  6 15:33:00 phantom kernel:  [__report_bad_irq+42/144] __report_bad_irq+0x2a/0x90

Apr  6 15:33:00 phantom kernel:  [<c010d74a>] __report_bad_irq+0x2a/0x90

Apr  6 15:33:00 phantom kernel:  [note_interrupt+108/160] note_interrupt+0x6c/0xa0

Apr  6 15:33:00 phantom kernel:  [<c010d83c>] note_interrupt+0x6c/0xa0

Apr  6 15:33:00 phantom kernel:  [do_IRQ+289/304] do_IRQ+0x121/0x130

Apr  6 15:33:00 phantom kernel:  [<c010db11>] do_IRQ+0x121/0x130

Apr  6 15:33:00 phantom kernel:  [rest_init+0/96] _stext+0x0/0x60

Apr  6 15:33:00 phantom kernel:  [<c0105000>] _stext+0x0/0x60

Apr  6 15:33:00 phantom kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20

Apr  6 15:33:00 phantom kernel:  [<c010be00>] common_interrupt+0x18/0x20

Apr  6 15:33:00 phantom kernel:  [rest_init+0/96] _stext+0x0/0x60

Apr  6 15:33:00 phantom kernel:  [<c0105000>] _stext+0x0/0x60

Apr  6 15:33:00 phantom kernel:  [default_idle+35/48] default_idle+0x23/0x30

Apr  6 15:33:00 phantom kernel:  [<c0109053>] default_idle+0x23/0x30

Apr  6 15:33:00 phantom kernel:  [cpu_idle+44/64] cpu_idle+0x2c/0x40

Apr  6 15:33:00 phantom kernel:  [<c01090bc>] cpu_idle+0x2c/0x40

Apr  6 15:33:00 phantom kernel:  [start_kernel+402/480] start_kernel+0x192/0x1e0

Apr  6 15:33:00 phantom kernel:  [<c0396772>] start_kernel+0x192/0x1e0

Apr  6 15:33:00 phantom kernel:  [unknown_bootoption+0/288] unknown_bootoption+0x0/0x120

Apr  6 15:33:00 phantom kernel:  [<c0396480>] unknown_bootoption+0x0/0x120

Apr  6 15:33:01 phantom kernel:

Apr  6 15:33:01 phantom kernel: handlers:

Apr  6 15:33:01 phantom kernel: [__crc_pci_find_bus+2323947/6460323] (usb_hcd_irq+0x0/0x70 [usbcore])

Apr  6 15:33:01 phantom kernel: [<e0949cf0>] (usb_hcd_irq+0x0/0x70 [usbcore])

Apr  6 15:33:01 phantom kernel: [__crc_pci_find_bus+2323947/6460323] (usb_hcd_irq+0x0/0x70 [usbcore])

Apr  6 15:33:01 phantom kernel: [<e0949cf0>] (usb_hcd_irq+0x0/0x70 [usbcore])

Apr  6 15:33:01 phantom kernel: Disabling IRQ #11

```

----------

## Onion Avenger

I, too, am having the same problem.

I have uhci-hcd as a module and am using a USB mouse.  I noticed the mouse dying and then the system hard freezing sometimes (sometimes it'll hard freeze, sometimes it won't) and was mystified as to its cause.  Finally I deduced that it happened whenever I was transferring things over the network.  I don't know if it's the speed of the transfer, or duration, or both, because I ran one of the 2.6.5 rc's for several days without any troubles (this is with normal web surfing and such).  But then someone downloaded something from my box via FTP and the IRQ 10 was disabled.  After more testing, I can now trigger this bug consistently by transferring files from my computer.

See this thread for my previous posts.  I am really eager to upgrade to the latest kernel rather than sticking with 2.6.3 or below.  I'm wondering if I should post to the lkml or something.  I've googled for this, but haven't had much success.  Sigh.

--Richie, the Onion Avenger

----------

## willkil

That's discouraging. I did read something about using gcc-2.95 instead of gcc-3.2 if you get weird interrupt errors. But if you have a working 2.6.3 kernel that was compiled with gcc-3.2, then this thread definitely needs to move to linux-kernel. I'd probably check the 2.6.4 Changelog first for usb related stuff and also grep the source code to try to isolate the bug myself before I posted to the mailing list. But it seems pretty clear that it is a kernel bug.

Googling didn't help me at all either. *shrug* I think we'll get it fixed pretty soon though.

----------

## Onion Avenger

Yeah, I had a perfect vanilla 2.6.3, and then I copied the .config to a vanilla 2.6.4, did a make oldconfig (no noteworthy changes, I thought) and then the 2.6.4 kernel would have the problems.  Same compiler, everything.  I tried 2.6.3-love6, which contains 2.6.3-mm4, so it looks like it was something in 2.6.3's -mm tree that got merged into the mainline.

I was able to do a quick look through 2.6.4's changelog, and saw several usb changes, including some which talked about IRQ's.  For the record, I only use the uhci module, not ehci or ohci.

I agree on reporting it to linux-kernel, but I'm a little busy right now at school to fill out a report and especially to poke around in the source code.  Perhaps someone else could get this reported?

Thanks!

----------

## willkil

I'll look at the source code. I'm not familiar with what the -love and -mm patch series include. You have it narrowed down so well, though. That will help a lot.

With Easter coming up, I don't know how soon I'll get it reported. But I'll post updated info in this thread.

Cheers,

William

----------

## Onion Avenger

The love patches provide several patches, but mainly the latest -mm patch.  The reason why I first noticed the problem under love was because it had -mm.    The -mm patches are by Andrew Morton (current 2.6 maintainer) and (to my understanding) is where kernel patches are tested in before they become official.  This is why I've experienced this problem under 2.6.4 and higher, 2.6.3-mm4, but not vanilla 2.6.3.  I'm not sure which -mm first has the problem, maybe I'll test that when I have time.

Good luck narrowing down the exact cause!  I'm glad I've been able to help.

--Richie, the Onion Avenger

----------

## DarkArctic

I've had the same problem for the first time a little while ago.  It only started after I upgraded from gentoo-dev-sources 2.6.3 to 2.6.5.  On my machine it was IRQ 18 which seems to be my on board HighPoint 370 RAID controller.  But my mouse did freeze up, I can't confirm anything related to a crash because i rebooted soon after the problems started.

-DarkArctic

----------

## Onion Avenger

Okay, I found myself with a few hours of free time this afternoon and here are my results:

I planed to test 2.6.3 (vanilla), and its -mm1, -mm2, -mm3, and -mm4 patches, and also 2.6.4 for good measure.  My testing procedure was thus: I would do a "make menuconfig" for 2.6.3, configure my kernel like how I always do (and it's always worked before these troubles), and then do a "make oldconfig" for the mm patches after that, and also 2.6.4.  I did this because my 2.6.3 .config works as expected, but the same .config (except for a few changes because of the new options each version increment adds) with the other versions then has these symptoms.

To trigger the bug, I ftp-ed into my box from a remote location, and then started downloading an 800 MB CD image.  I would watch my system logs to see if the irq was disabled.

Here are my results:

2.6.3 was just fine, as expected.

2.6.3-mm1 disabled irq 10!!

2.6.3-mm2 gave me some errors on compiling parallel port stuff, so I just disabled that (I don't need it anyway), and after my network testing it also disabled irq #10.

2.6.3-mm3 I didn't test since -mm2 and -mm1 already disabled the irq

2.6.3-mm4 I didn't test either

2.6.4 also disabled the irq

Hm, so the problem is 2.6.3-mm1 or earlier!  I'll try testing the earlier mm patches.  They can all be found here.

Here is the output in my kernel log file for each time:

(2.6.4)

```

Apr 13 15:19:50 ecthelion irq 10: nobody cared!

Apr 13 15:19:50 ecthelion Call Trace:

Apr 13 15:19:50 ecthelion [<c010d60a>] __report_bad_irq+0x2a/0x90

Apr 13 15:19:50 ecthelion [<c010d6fc>] note_interrupt+0x6c/0xa0

Apr 13 15:19:50 ecthelion [<c010d9d1>] do_IRQ+0x121/0x130

Apr 13 15:19:50 ecthelion [<c010bcf4>] common_interrupt+0x18/0x20

Apr 13 15:19:50 ecthelion 

Apr 13 15:19:50 ecthelion handlers:

Apr 13 15:19:50 ecthelion [<c02ccae0>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:19:50 ecthelion [<c02ccae0>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:19:50 ecthelion [<c02ccae0>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:19:50 ecthelion Disabling IRQ #10
```

(2.6.3-mm1)

```

Apr 13 15:23:55 ecthelion irq 10: nobody cared!

Apr 13 15:23:55 ecthelion Call Trace:

Apr 13 15:23:55 ecthelion [<c010e9ca>] __report_bad_irq+0x2a/0x90

Apr 13 15:23:55 ecthelion [<c010eabc>] note_interrupt+0x6c/0xa0

Apr 13 15:23:55 ecthelion [<c010ed91>] do_IRQ+0x121/0x130

Apr 13 15:23:55 ecthelion [<c0107000>] rest_init+0x0/0x60

Apr 13 15:23:55 ecthelion [<c039dae8>] common_interrupt+0x18/0x20

Apr 13 15:23:55 ecthelion [<c0107000>] rest_init+0x0/0x60

Apr 13 15:23:55 ecthelion [<c010b053>] default_idle+0x23/0x30

Apr 13 15:23:55 ecthelion [<c010b0bc>] cpu_idle+0x2c/0x40

Apr 13 15:23:55 ecthelion [<c049277d>] start_kernel+0x18d/0x1d0

Apr 13 15:23:55 ecthelion [<c0492480>] unknown_bootoption+0x0/0x120

Apr 13 15:23:55 ecthelion 

Apr 13 15:23:55 ecthelion handlers:

Apr 13 15:23:55 ecthelion [<c02d1810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:23:55 ecthelion [<c02d1810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:23:55 ecthelion [<c02d1810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:23:55 ecthelion Disabling IRQ #10
```

(2.6.3-mm2)

```

Apr 13 15:31:55 ecthelion irq 10: nobody cared!

Apr 13 15:31:55 ecthelion Call Trace:

Apr 13 15:31:55 ecthelion [<c010e9ca>] __report_bad_irq+0x2a/0x90

Apr 13 15:31:55 ecthelion [<c010eabc>] note_interrupt+0x6c/0xa0

Apr 13 15:31:55 ecthelion [<c010ed91>] do_IRQ+0x121/0x130

Apr 13 15:31:55 ecthelion [<c0398f08>] common_interrupt+0x18/0x20

Apr 13 15:31:55 ecthelion [<c0126980>] do_softirq+0x40/0xa0

Apr 13 15:31:55 ecthelion [<c010ed6d>] do_IRQ+0xfd/0x130

Apr 13 15:31:55 ecthelion [<c0107000>] rest_init+0x0/0x60

Apr 13 15:31:55 ecthelion [<c0398f08>] common_interrupt+0x18/0x20

Apr 13 15:31:55 ecthelion [<c0107000>] rest_init+0x0/0x60

Apr 13 15:31:55 ecthelion [<c010b053>] default_idle+0x23/0x30

Apr 13 15:31:55 ecthelion [<c010b0bc>] cpu_idle+0x2c/0x40

Apr 13 15:31:55 ecthelion [<c048c77d>] start_kernel+0x18d/0x1d0

Apr 13 15:31:55 ecthelion [<c048c480>] unknown_bootoption+0x0/0x120

Apr 13 15:31:55 ecthelion 

Apr 13 15:31:55 ecthelion handlers:

Apr 13 15:31:55 ecthelion [<c02cc810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:31:55 ecthelion [<c02cc810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:31:55 ecthelion [<c02cc810>] (usb_hcd_irq+0x0/0x70)

Apr 13 15:31:55 ecthelion Disabling IRQ #10
```

I wonder why the error messages are all slightly different.  I guess I should test repeatedly under each version, but I didn't have THAT much time  :Smile: 

BTW, here are my IRQs:

```
           CPU0       

  0:     789762    IO-APIC-edge  timer

  1:       4290    IO-APIC-edge  i8042

  2:          0          XT-PIC  cascade

  8:          2    IO-APIC-edge  rtc

  9:          0   IO-APIC-level  acpi

 10:     781159   IO-APIC-level  uhci_hcd, uhci_hcd, uhci_hcd

 12:      30494   IO-APIC-level  VIA8233

 14:      18018    IO-APIC-edge  ide0

 15:         19    IO-APIC-edge  ide1

 16:      57028   IO-APIC-level  nvidia

 19:     758209   IO-APIC-level  eth0

NMI:          0 

LOC:     787723 

ERR:          0

MIS:          0

```

So IRQ 10 is my USB interrupt.  This is why my mouse dies.  (I think the reason there are three "uhci_hcd" listed is because my mobo has three built-in hubs.)  Now to figure out why network activity would do this.  I'm still not sure whether it's the fact that lots of network activity happens for several straight minutes or the speed of the data that does this.

One last thing: here I have the config (note I renamed them to take off the .) for each kernel I tested.  I also put some of my system info in the "sysinfo" file (lspci, cat /proc/interrupts, etc) if that helps.

When/if I have some more time, I'll try testing the earlier mm patches (like to the 2.6.3-rc's and such) to isolate the exact patch that does this.

Thanks again and good luck willkil!

--Richie, the Onion Avenger

----------

## gearmonk

Not sure if this is an option for you, but my problems with this bug cleared up when I disabled ACPI. Currently running 2.6.5-love3 with hotplug and udev, and USB works perfectly. ACPI never gave me anything useful on my system anyway. I know it probably isn't the real cause, since I've had ACPI enabled in previous kernels, but it works for now...

----------

## Onion Avenger

Thanks for the suggestion, gearmonk.  I tried disabling ACPI, but that didn't do anything.  On a hunch, I disabled the IO-APIC option (not the Local APIC support, since disabling that would give me errors during kernel compilation), and that seemed to work!  I tested it under 2.6.3-mm1 and under 2.6.5-love4.  I am currently running -love4 without any troubles.  I'll open up a few torrents overnight and let some serious uploading begin and see what happens over the next few days.  But this IO-APIC thing seems to work!  This is strange, because I've always had it enabled before...

Oh, one other thing:  When IO-APIC is enabled, I get my USB stuff on IRQ 10 and my network card on 19.  When it's disabled both my usb and network irqs are sharing #10.  

```
ecthelion 11:25 PM root # cat /proc/interrupts

CPU0

0:      85953          XT-PIC  timer

1:        109          XT-PIC  i8042

2:          0          XT-PIC  cascade

8:          2          XT-PIC  rtc

9:          1          XT-PIC  acpi

10:        864          XT-PIC  uhci_hcd, uhci_hcd, uhci_hcd, eth0

12:          0          XT-PIC  VIA8233

14:       1750          XT-PIC  ide0

15:         17          XT-PIC  ide1

NMI:          0

LOC:      85811

ERR:        714

```

This slightly worries me, since I don't think they should be sharing.  But at least my mouse works  :Wink: .  I'm not terribly concerned since the only usb device I use is my optical mouse, which is a low bandwidth device.

Lastly, I won't be using this computer much longer, the next one I'm getting will be a totally different mobo/cpu so this issue may never appear.  This also means I can't really help test this issue out in the future.  Speaking of which, can everyone else disable their irq through network usage like what I was doing, or was that specific to me?  I still don't know why that network usage would interfere with the usb irq.

Thanks everyone,

--Richie, the Onion Avenger

----------

## ArloWhite

I still have the problem with gentoo-dev-2.6.5

I do have ACPI enabled, as well as uhci; I'm also using SMP.  It sounds like these may be to blame.

I seem to trigger the problem when I do anything related to ALSA or specialized graphics.  (fglrx)  I often have this error precisly when I click next song with xmms, or sometimes with tvtime and winex.  However, sometimes I can go a whole session with xmms and never trigger the error.  I can't really seem to find a pattern to it.  I don't really do many large downloads and haven't noticed the problem being related to that.  As far as I can tell, this problem occurs fairly randomnly on my machine.

Here's the error again, you'll notice that it also disabled IRQ 18 this time.  (EMU10K1)

```
handlers:

[<f08a46e0>] (snd_emu10k1_interrupt+0x0/0x420 [snd_emu10k1])

Disabling IRQ #18

irq 10: nobody cared!

Call Trace:

 [<c010bada>] __report_bad_irq+0x2a/0x90

 [<c010bbd0>] note_interrupt+0x70/0xb0

 [<c010bf10>] do_IRQ+0x160/0x1a0

 [<c0109fe8>] common_interrupt+0x18/0x20

 [<c0107030>] default_idle+0x0/0x40

 [<c010705c>] default_idle+0x2c/0x40

 [<c01070eb>] cpu_idle+0x3b/0x50

 [<c0124668>] printk+0x178/0x1f0

handlers:

[<c02ce260>] (usb_hcd_irq+0x0/0x70)

[<c02ce260>] (usb_hcd_irq+0x0/0x70)

Disabling IRQ #10

```

----------

## ArloWhite

This is a know kernel bug.  See:

http://bugme.osdl.org/show_bug.cgi?id=2243

----------

## nahpets

Can someone tell me how to disable IO-APIC in "gentoo-dev-sources" 2.6.5?  The option doesn't seem to be in menuconfig, and when I try editing the .config file with vim, the changes I make are undone by "make".

----------

## mrnegitoro

Hi,

I have the same problem with IRQ #12, a usb mouse and gentoo-dev-sources 2.6.5. So there isn't a fix yet?

Crap.

----------

## nahpets

 *nahpets wrote:*   

> Can someone tell me how to disable IO-APIC in "gentoo-dev-sources" 2.6.5?  The option doesn't seem to be in menuconfig, and when I try editing the .config file with vim, the changes I make are undone by "make".

 

I figured it out after searching through "/usr/src/linux/arch/i386/Kconfig" for APIC related stuff...

The reason I couldn't see the "APIC" option in menuconfig is that "SMP" was enabled (don't know why). The "Kconfig" file shows:

```

config X86_IO_APIC

        bool

        depends on !SMP && X86_UP_IOAPIC

        default y

```

Which means that you only see the option in menuconfig when SMP is disabled.  Hope my wasted time helps someone else...

----------

## ArloWhite

When I tried disabling IO_APIC by editing the .config file, it actually didn't disable.  I checked /proc/config.gz after booting the new image and found that IO_APIC was re-enabled.  I have a feeling there's a good reason for this.  In any case, it didn't work for me and I actually had the freeze soon after.

Just a reminder there's a kernel bug here:

http://bugzilla.kernel.org/show_bug.cgi?id=2243

And a gentoo bug report here:

https://bugs.gentoo.org/show_bug.cgi?id=46553

Sounds like we should just wait for the patch Len mentioned in my duplicate bug report.

"VIA Apollo PRO133x quirk is already filed. 

We'll put the patch in the existing bug report, please test it when it is ready. 

thanks, 

-Len"

This other bug report has a bunch of patches but I haven't tried them and they may not fix this specific problem.

http://bugzilla.kernel.org/show_bug.cgi?id=2366

----------

## Onion Avenger

Awesome work, Arlo!  However, I'd like to add that disabling ACPI didn't seem to help me, at least with using the "acpi=off" boot argument.  It wasn't until I turned off IO-APIC in the kernel config that it worked.  (And ACPI is still on.)

----------

## Aonoa

This still is not working in 2.6.6.. rather annoying that I have to use 2.6.3 still if I want it to work. Removing acpi only made my mouse not work at all.. I'm on a SMP system, so the IO-APIC isn't enabled in my kernel. I found that I could force uhci_hcd to unload with the -f option and reloading it returned it's IRQ. A bad fix.. but works somewhat. Anyone know a better solution?

----------

