linux-kernel - Re: Problem: irq 217: nobody cared + backtrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0608031158560.7384-100000@iolanthe.rowland.org>
Date:	Thu, 3 Aug 2006 12:08:20 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jesper Juhl <jesper.juhl@...il.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<linux-usb-devel@...ts.sourceforge.net>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: Problem: irq 217: nobody cared + backtrace

On Thu, 3 Aug 2006, Jesper Juhl wrote:

> Hi,
> 
> A server of mine just dumped a backtrace (below).
> The machine seems to be running fine, but it would be nice to know
> what the cause of this dump is.
> The box is running 2.6.18-rc3-git3
> Full dmesg output is attached.
> If more info than what is below is needed, then just ask and I'll
> provide it if I can.
> 
> 
> e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
> eth0.20: add 01:00:5e:00:00:01 mcast address to master interface
> IA-32 Microcode Update Driver: v1.14a <tigran@...itas.com>
> irq 217: nobody cared (try booting with the "irqpoll" option)
>  [<c0103a3c>] show_trace_log_lvl+0x152/0x165
>  [<c0103a5e>] show_trace+0xf/0x13
>  [<c0103b59>] dump_stack+0x15/0x19
>  [<c013846e>] __report_bad_irq+0x24/0x7f
>  [<c0138552>] note_interrupt+0x6b/0xd5
>  [<c0137ca8>] __do_IRQ+0xf4/0x100
>  [<c01050a1>] do_IRQ+0x95/0xbc
>  [<c0103502>] common_interrupt+0x1a/0x20
>  [<c02d61b7>] uhci_irq+0x27/0x153
>  [<c02c45e8>] usb_hcd_irq+0x24/0x53
>  [<c0137b84>] handle_IRQ_event+0x26/0x56
>  [<c0137c4c>] __do_IRQ+0x98/0x100
>  [<c01050a1>] do_IRQ+0x95/0xbc
>  [<c0103502>] common_interrupt+0x1a/0x20
>  [<c0100e64>] mwait_idle+0x30/0x35
>  [<c0100d45>] cpu_idle+0x78/0x81
>  [<c04bf7fb>] start_kernel+0x173/0x19d
>  [<c0100210>] 0xc0100210
> DWARF2 unwinder stuck at 0xc0100210
> Leftover inexact backtrace:
>  =======================
> handlers:
> [<c02c45c4>] (usb_hcd_irq+0x0/0x53)
> Disabling IRQ #217

This beats me.  You didn't have any USB devices attached, did you?  There 
was nothing in the dmesg log about them.

Since no device was using IRQ 217 except for the UHCI controller, there 
seem to be only two possibilities.  Either the controller is broken and 
generating IRQs for no reason at all, or else some other device is using 
IRQ 217 when the system thinks it should be using a different line.

Has this happened more than once?  In case it happens again, here's how 
you can get more information.  Turn on CONFIG_USB_DEBUG and 
CONFIG_DEBUG_FS, and mount a debugfs filesystem somewhere (say 
/sys/kernel/debug).  Then after the problem occurs, save a copy of 

	/sys/kernel/debug/uhci/0000:00:1d.1

That will indicate whether the UHCI controller thinks it is sending an 
interrupt request.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/