By the way, have you tried to boot with irqpoll as the kernel says ? And i suppose you use wheezy according to your kernel (3.2.65) version, so did you try to upgrade kernel from backport (3.16.7) ?
2015-04-23 14:26 GMT+02:00 Kynn Jones <kyn...@gmail.com>: > 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 >>> >>> >> >
