Re: Problem: irq 217: nobody cared + backtrace

From: Alan Stern
Date: Thu Aug 03 2006 - 12:06:04 EST


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@xxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/