Thanks for your comment. It turns out that unhandled IRQ16 happens irrespective of which USB port the mouse is connected to, or even if the mouse is connected at all at the time the system goes to sleep (in the latter case, when the mouse is re-connected, it still shows the same lag). (I posted about this in the bug report I sent: https://bugzilla.kernel.org/show_bug.cgi?id=97131)
I think the mouse here is an "innocent bystander caught in the crossfire" :) kj On Thu, Apr 23, 2015 at 6:25 AM, claude juif <claude.j...@gmail.com> wrote: > Hi, > > Did the mouse lags occurs on all usb port ? Because you lspci return usb1 > on IRQ16 and usb2 on IRQ23. > > So if your problem is related to IRQ16, changing USB port might resolv the > problem. If the problem still there, i guess IRQ16 have nothing to do with > your mouse lags. > > Regards, > > 2015-04-22 17:33 GMT+02:00 Kynn Jones <kyn...@gmail.com>: > >> On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones <kyn...@gmail.com> wrote: >> >> > 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 >> >> Correction: when I looked again I did find a file for 00.03.0: >> >> /sys/devices/pci0000:00/0000:00:03.0 >> >> I'm not sure why I missed it the first time. >> >> > I went ahead and added the line >> >> > echo 1 > /sys/devices/pci0000:00/0000:00:1b.0/remove >> >> > to /etc/rc.local, and rebooted. >> >> I repeated the same thing once more with this line instead: >> >> echo 1 > /sys/devices/pci0000:00/0000:00:03.0/remove >> >> ...and now after rebooting the IRQ 16 line of /proc/interrupts >> shows only one driver: >> >> # grep '^ 16:' /proc/interrupts >> 16: 1211 0 0 0 >> IR-IO-APIC-fasteoi ehci_hcd:usb1 >> >> But, unfortunately, this turned out to be a red herring: the >> unhandled IRQ 16 error continues to happen, and along with it the >> mouse that, as it were, "wakes drunk from sleep". (At least the >> system's sound continues to work fine, AFAICT.) >> >> Now it looks like the problem is with the ehci_hcd driver. >> >> In this case, I don't think that disabling the driver is an >> option, so I decided to send a full bug report to the >> debian-kernel list, here: >> >> https://lists.debian.org/debian-kernel/2015/04/msg00348.html >> >> Putting aside the main issue (the problem with the mouse) I now >> have the additional (but far less pressing) question of which of >> the two instances of snd_hda_intel I should keep around? >> >> kj >> >> >
