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 <[EMAIL PROTECTED]> > 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel