[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Need help fixing an unhandled irq

I did boot with irqpoll, and indeed the unhandled interrupt does not occur, but my understanding is that the irqpoll option is a temporary measure (maybe to get past anotherwise fatal unhandled interrupt), but not a permanent fix.  (Because it is inefficient for the kernel to perform such polling?  I'm not sure.)

I have not tried the upgrade kernel from backport.  I'll give that a shot.  Thanks!

On Thu, Apr 23, 2015 at 8:46 AM, claude juif <claude.juif@gmail.com> wrote:
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 <kynnjo@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" :)


On Thu, Apr 23, 2015 at 6:25 AM, claude juif <claude.juif@gmail.com> wrote:

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.


2015-04-22 17:33 GMT+02:00 Kynn Jones <kynnjo@gmail.com>:
On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones <kynnjo@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:


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:


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?


Reply to: