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.)
