When my computer returns from sleep, the mouse has a lag so severe that any operation dependent on use of the mouse becomes all but impossible.
Looking at the kernel logs I found a message that seems to be related to the problem described above; it's about an unhandled irq:
Apr 21 21:51:04 capitan kernel: [ 61.599288] irq 16: nobody cared (try booting with the "irqpoll" option)
Apr 21 21:51:04 capitan kernel: [ 61.599300] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.65-1+deb7u2
Apr 21 21:51:04 capitan kernel: [ 61.599305] Call Trace:
Apr 21 21:51:04 capitan kernel: [ 61.599309] <IRQ> [<ffffffff81092ddd>] ? __report_bad_irq+0x2c/0xb5
Apr 21 21:51:04 capitan kernel: [ 61.599331] [<ffffffff810931e2>] ? note_interrupt+0x1b8/0x23a
Apr 21 21:51:04 capitan kernel: [ 61.599339] [<ffffffff81091554>] ? handle_irq_event_percpu+0x15f/0x17d
Apr 21 21:51:04 capitan kernel: [ 61.599346] [<ffffffff810915a6>] ? handle_irq_event+0x34/0x52
Apr 21 21:51:04 capitan kernel: [ 61.599356] [<ffffffff8106c305>] ? arch_local_irq_save+0x11/0x17
Apr 21 21:51:04 capitan kernel: [ 61.599364] [<ffffffff81093959>] ? handle_fasteoi_irq+0x7c/0xaf
Apr 21 21:51:04 capitan kernel: [ 61.599374] [<ffffffff8100fa51>] ? handle_irq+0x1d/0x21
Apr 21 21:51:04 capitan kernel: [ 61.599382] [<ffffffff8100f62a>] ? do_IRQ+0x42/0x98
Apr 21 21:51:04 capitan kernel: [ 61.599392] [<ffffffff813511ae>] ? common_interrupt+0x6e/0x6e
Apr 21 21:51:04 capitan kernel: [ 61.599396] <EOI> [<ffffffff81024404>] ? lapic_next_event+0xe/0x13
Apr 21 21:51:04 capitan kernel: [ 61.599429] [<ffffffffa01c835b>] ? arch_local_irq_enable+0x7/0x8 [processor]
Apr 21 21:51:04 capitan kernel: [ 61.599442] [<ffffffffa01c90b3>] ? acpi_idle_enter_c1+0x8d/0xb3 [processor]
Apr 21 21:51:04 capitan kernel: [ 61.599452] [<ffffffff8127180d>] ? cpuidle_idle_call+0xec/0x179
Apr 21 21:51:04 capitan kernel: [ 61.599461] [<ffffffff8100d242>] ? cpu_idle+0xa5/0xf2
Apr 21 21:51:04 capitan kernel: [ 61.599470] [<ffffffff816aab3b>] ? start_kernel+0x3bd/0x3c8
Apr 21 21:51:04 capitan kernel: [ 61.599479] [<ffffffff816aa140>] ? early_idt_handlers+0x140/0x140
Apr 21 21:51:04 capitan kernel: [ 61.599487] [<ffffffff816aa3c4>] ? x86_64_start_kernel+0x104/0x111
Apr 21 21:51:04 capitan kernel: [ 61.599491] handlers:
Apr 21 21:51:04 capitan kernel: [ 61.599508] [<ffffffffa000c216>] usb_hcd_irq
Apr 21 21:51:04 capitan kernel: [ 61.599517] [<ffffffffa02d0cbd>] azx_interrupt
Apr 21 21:51:04 capitan kernel: [ 61.599522] Disabling IRQ #16
Looking at the output from `/proc/interrupts`
CPU0 CPU1 CPU2 CPU3
0: 53 0 0 0 IR-IO-APIC-edge timer
1: 3 0 0 0 IR-IO-APIC-edge i8042
8: 1 0 0 0 IR-IO-APIC-edge rtc0
9: 0 0 0 0 IR-IO-APIC-fasteoi acpi
12: 4 0 0 0 IR-IO-APIC-edge i8042
* 16: 29065 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1, snd_hda_intel
23: 37100 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb2
40: 0 0 0 0 DMAR_MSI-edge dmar0
41: 0 0 0 0 DMAR_MSI-edge dmar1
42: 11425 0 0 0 IR-PCI-MSI-edge eth0
43: 53906 0 0 0 IR-PCI-MSI-edge ahci
44: 60 0 0 0 IR-PCI-MSI-edge xhci_hcd
* 45: 235 0 0 0 IR-PCI-MSI-edge snd_hda_intel
NMI: 102 60 51 95 Non-maskable interrupts
LOC: 67413 40257 57679 43949 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 102 60 51 95 Performance monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RES: 150105 180510 183193 156750 Rescheduling interrupts
CAL: 396 638 603 655 Function call interrupts
TLB: 2362 3182 3646 3919 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 13 13 13 13 Machine check polls
ERR: 0
MIS: 0
...I see that for irq 16 there are two entries in the last column: ehci_hcd:usb1 and snd_hda_intel, and that there is another snd_hda_intel entry for irq 45. (See the rows indicated by the added asterisks.)
(FWIW, the system's sound is fine AFAICT.)
I see a glimmer of hope in this (apparent?) redundancy. My thinking goes like this: (1) *maybe* the snd_hda_intel listed for interrupt 16 is what's responsible for the unhandled interrupt, and (2) *maybe* this snd_hda_intel can be disabled altogether, in light of the snd_hda_intel listed for interrupt 45? But I really don't know what I'm talking about. More importantly, even if these wishful guesses turn out to be correct, I don't know how to go about disabling the snd_hda_intel associated with irq 16.
I would greatly appreciate any clues on fixing this unhandled interrupt.
Many thanks in advance!
kj
PS: FWIW, here's the output of lspci (I've added asterisk to lines of possible interest):
00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Haswell Integrated Graphics Controller (rev 06)
* 00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation Lynx Point MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04)
00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #2 (rev 04)
* 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev d4)
00:1c.4 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #5 (rev d4)
00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 04)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 04)
00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 04)
(The output of dmesg is ~900 lines; I'll gladly post it if that's the place to look to diagnose this problem.)