On Tue, Apr 21, 2015 at 8:49 PM, Kynn Jones <kyn...@gmail.com> wrote:
> 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.
>
OK, I found a way to turn off one of the two snd_hda_intel, but it turned
out to be the one on IRQ 45. (In any case, doing this did not solve the
problem.)
The method I used was
1. find the prefix of the audio device(s) in the output of lspci
2. search for a path under /sys/devices with this prefix in the basename
3. add a line of the form
echo 1 > /path/found/in/previous/step/remove
When did step (1) I found two candidate prefixes 00:03.0 and 00.1b.0, from
the lines
00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller
(rev 06)
00:1b.0 Audio device: Intel Corporation Lynx Point High Definition
Audio Controller (rev 04)
but in step (2) I was able to find only one matching path, namely
/sys/devices/pci0000:00/0000:00:1b.0
I went ahead and added the line
echo 1 > /sys/devices/pci0000:00/0000:00:1b.0/remove
to /etc/rc.local, and rebooted. Then I saw that the line
45: 235 0 0 0 IR-PCI-MSI-edge
snd_hda_intel
was missing from the listing from /proc/interrupts, but the line
16: 18185 0 0 0 IR-IO-APIC-fasteoi
ehci_hcd:usb1, snd_hda_intel
was still there. Not surprisingly (given that the situation for IRQ 16
appears unchanged), the original problem with the lagging mouse persists.
But at least now I've narrowed my question to: how to turn off
00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller
(rev 06)
?
Does anyone have any ideas?
Thanks in advance!
kj
