I decided to try out the Ubuntu 10.10 RC on my workstation today. The install worked fine, but the mouse and keyboard (both of which is usb) are unbearably laggy. This was also the case when I ran it from the live cd.

The strange part is that it works fine for the first few seconds when entering X. Then something happens in the background, and the mouse all of a sudden behaves like I'm playing some demanding 3d game on the highest setting. The keyboard is also laggy, and if I press more than a single key per second the key will be dropped, and only about every fifth character will actually appear on screen. Even stranger is that this lag also is present when a use ctrl+alt+f1 to switch to console mode.

If I immediately switch to console mode when booting, it works fine. Then when I switch back to X, it takes a couple of seconds and then it happens again.

I've checked the logs, and the most suspicious message is:

Oct  3 20:16:16 CHURCHILL kernel: [   70.868940] irq 19: nobody cared (try booting with the "irqpoll" option)
Oct  3 20:16:16 CHURCHILL kernel: [   70.868946] Pid: 0, comm: swapper Not tainted 2.6.35-22-generic #33-Ubuntu
Oct  3 20:16:16 CHURCHILL kernel: [   70.868948] Call Trace:
Oct  3 20:16:16 CHURCHILL kernel: [   70.868950]  <IRQ>  [<ffffffff810cba5b>] __report_bad_irq+0x2b/0xa0
Oct  3 20:16:16 CHURCHILL kernel: [   70.868961]  [<ffffffff810cbc5c>] note_interrupt+0x18c/0x1d0
Oct  3 20:16:16 CHURCHILL kernel: [   70.868967]  [<ffffffff81085d10>] ? sched_clock_tick+0x60/0x90
Oct  3 20:16:16 CHURCHILL kernel: [   70.868970]  [<ffffffff810cc45d>] handle_fasteoi_irq+0xdd/0x110
Oct  3 20:16:16 CHURCHILL kernel: [   70.868974]  [<ffffffff8100cb12>] handle_irq+0x22/0x30
Oct  3 20:16:16 CHURCHILL kernel: [   70.868978]  [<ffffffff81590b2c>] do_IRQ+0x6c/0xf0
Oct  3 20:16:16 CHURCHILL kernel: [   70.868981]  [<ffffffff81589713>] ret_from_intr+0x0/0x11
Oct  3 20:16:16 CHURCHILL kernel: [   70.868983]  <EOI>  [<ffffffff810360fb>] ? native_safe_halt+0xb/0x10
Oct  3 20:16:16 CHURCHILL kernel: [   70.868990]  [<ffffffff81012ecd>] default_idle+0x3d/0x90
Oct  3 20:16:16 CHURCHILL kernel: [   70.868995]  [<ffffffff81008da3>] cpu_idle+0xb3/0x110
Oct  3 20:16:16 CHURCHILL kernel: [   70.868999]  [<ffffffff8156f6fa>] rest_init+0x8a/0x90
Oct  3 20:16:16 CHURCHILL kernel: [   70.869004]  [<ffffffff81aedc9d>] start_kernel+0x387/0x390
Oct  3 20:16:16 CHURCHILL kernel: [   70.869007]  [<ffffffff81aed341>] x86_64_start_reservations+0x12c/0x130
Oct  3 20:16:16 CHURCHILL kernel: [   70.869011]  [<ffffffff81aed43f>] x86_64_start_kernel+0xfa/0x109
Oct  3 20:16:16 CHURCHILL kernel: [   70.869013] handlers:
Oct  3 20:16:16 CHURCHILL kernel: [   70.869014] [<ffffffff81404bb0>] (usb_hcd_irq+0x0/0x90)
Oct  3 20:16:16 CHURCHILL kernel: [   70.869019] [<ffffffff81404bb0>] (usb_hcd_irq+0x0/0x90)
Oct  3 20:16:16 CHURCHILL kernel: [   70.869022] [<ffffffff81404bb0>] (usb_hcd_irq+0x0/0x90)
Oct  3 20:16:16 CHURCHILL kernel: [   70.869026] Disabling IRQ #19

IRQ related issues, is from what I can tell, rather common. However, most of them seems to be related to shared interrupts, but on my computer IRQ 19 is used exclusively by the USB controller:

root@CHURCHILL:/home/emil# cat /proc/interrupts
  0:         26   IO-APIC-edge      timer
  1:          2   IO-APIC-edge      i8042
  7:          1   IO-APIC-edge      parport0
  8:          0   IO-APIC-edge      rtc0
  9:          1   IO-APIC-fasteoi   acpi, firewire_ohci
 12:          4   IO-APIC-edge      i8042
 14:          0   IO-APIC-edge      pata_atiixp
 15:       1004   IO-APIC-edge      pata_atiixp
 17:        154   IO-APIC-fasteoi   ATI IXP
 18:       6164   IO-APIC-fasteoi   radeon, hda_intel
 19:    2000002   IO-APIC-fasteoi   ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
 20:       9097   IO-APIC-fasteoi   eth0, eth1
 22:      13702   IO-APIC-fasteoi   sata_sil
NMI:          0   Non-maskable interrupts
LOC:     105505   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
PND:          0   Performance pending work
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          4   Machine check polls
ERR:          1
MIS:          0

The on other person I've been able to found that had similar problems resorted to using irqpoll, as suggested by the kernel message. However, he reported that the inputs didn't work at all without that option, which makes me suggest that this might not really be IRQ related after all. Especially since it works fine for a while.

lspci lists the USB controller as ATI Technologies Inc IXP SB400 USB Host Controller.

Any suggestions would be greatly appreciated.

  • You are not alone. I noticed a similar behaviour over the weekend with my 10.10 virtual machine. But I don't have the necessary knowledge to add any technical observations like log files. So if someone has an answer or some things to inspect and try out, I would be willing to do so... – Bananeweizen Oct 4 '10 at 17:05
  • @Banan, The most interesting part is that I observed the same issue later in Windows 7. Millions of interrupts was being sent from the usb driver. On the windows side, it turned out to be because of some kind of conflict with microsofts hd audio driver, which uses IRQ 18 on my computer (the usb controller uses IRQ 19). I tried unloading the corresponding kernel modules in linux, but it didn't resolve the issue. On the other hand, it might be better to prevent the modules from loading in the first place. – Emil H Oct 4 '10 at 19:15
  • Three years later and apparently this bug is still around. I started experiencing these exact same symptoms a few months ago (running 12.04 then and now). At first I thought it was somehow related to suspending my desktop on a daily basis instead of shutting it down (I typically have a busy workspace, so it's easier to just suspend instead of re-opening everything). But now, I'm getting this problem even with a cold boot. Typically occurs a number of hours after log in. It also appears to be very sporadic. CPU usage is definitely not related. – Toasty Aug 19 '13 at 10:31
  • @Toasty I could blame faulty hardware. – Braiam Aug 27 '13 at 22:16

Maybe its not kernel bug, but some user process hogs resources? For example, epic gnome-settings-daemon (https://bugs.launchpad.net/bugs/625793)? Start System Monitor, open All processes from menu and sort by CPU usage, you may find answer...

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.