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
# scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux server 2.6.18-rc3-git3 #1 SMP Thu Aug 3 13:28:08 CEST 2006 i686 GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
binutils 2.15
util-linux 2.12p
mount 2.12p
module-init-tools 3.2-pre1
e2fsprogs 1.37
xfsprogs 2.6.20
nfs-utils 1.0.6
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
udev 056
Modules Loaded sky2 piix ide_core eeprom
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 3
cpu MHz : 3192.358
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips : 6388.63
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 3
cpu MHz : 3192.358
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips : 6384.44
# cat /proc/interrupts
CPU0 CPU1
0: 175546 3503 IO-APIC-edge timer
1: 3 5 IO-APIC-edge i8042
8: 3 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
50: 1 0 PCI-MSI sky2
169: 5177874 1 IO-APIC-level uhci_hcd:usb2, eth0
177: 26052 26 IO-APIC-level 3w-9xxx
185: 32334 35 IO-APIC-level 3w-9xxx
193: 17290 14 IO-APIC-level 3w-9xxx
201: 23050 16 IO-APIC-level 3w-9xxx, libata, uhci_hcd:usb4
209: 0 0 IO-APIC-level ehci_hcd:usb1
217: 99932 68 IO-APIC-level uhci_hcd:usb3
NMI: 178992 178964
LOC: 178936 178936
ERR: 0
MIS: 0
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
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
On 03/08/06, Alan Stern <[email protected]> wrote:
>
> Has this happened more than once?
Seems to happen consistently after ~100000 interrupts.
> 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
>
# cat /sys/kernel/debug/uhci/0000:00:1d.1
Root-hub state: auto-stopped FSBR: 0
HC status
usbcmd = 0048 Maxp32 CF EGSM
usbstat = 0020 HCHalted
usbint = 0002
usbfrnum = (1)160
flbaseadd = 37428160
sof = 40
stat1 = 0080
stat2 = 0080
Most recent frame: 458 (88) Last ISO frame: 458 (88)
> That will indicate whether the UHCI controller thinks it is sending an
> interrupt request.
>
And just for completenes, here's the backtrace I got just before
saving the above info :
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
[<c0137b7e>] handle_IRQ_event+0x20/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
[<c04cc7fb>] start_kernel+0x173/0x19d
[<c0100210>] 0xc0100210
DWARF2 unwinder stuck at 0xc0100210
Leftover inexact backtrace:
=======================
handlers:
[<c02c5c22>] (usb_hcd_irq+0x0/0x53)
Disabling IRQ #217
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Thu, 2006-08-03 at 12:08 -0400, Alan Stern wrote:
> Has this happened more than once?
In my case (it very different), all the time.
I also got :
uhci_hcd 0000:00:10.1: host controller process error, something bad
happened!
uhci_hcd 0000:00:10.1: host controller halted, very bad!
uhci_hcd 0000:00:10.1: HC died; cleaning up
usb 3-2: USB disconnect, address 2
> 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
can you explain to me how I mount debugfs filesystem ? please
Thanks,
--
Sérgio M. B.
On Fri, 4 Aug 2006, Jesper Juhl wrote:
> On 03/08/06, Alan Stern <[email protected]> wrote:
> >
> > Has this happened more than once?
>
> Seems to happen consistently after ~100000 interrupts.
>
> > 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
> >
>
> # cat /sys/kernel/debug/uhci/0000:00:1d.1
> Root-hub state: auto-stopped FSBR: 0
> HC status
> usbcmd = 0048 Maxp32 CF EGSM
> usbstat = 0020 HCHalted
> usbint = 0002
> usbfrnum = (1)160
> flbaseadd = 37428160
> sof = 40
> stat1 = 0080
> stat2 = 0080
> Most recent frame: 458 (88) Last ISO frame: 458 (88)
>
>
> > That will indicate whether the UHCI controller thinks it is sending an
> > interrupt request.
And it shows that the controller is idle. No IRQ should be pending.
> And just for completenes, here's the backtrace I got just before
> saving the above info :
>
> 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
> [<c0137b7e>] handle_IRQ_event+0x20/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
> [<c04cc7fb>] start_kernel+0x173/0x19d
> [<c0100210>] 0xc0100210
> DWARF2 unwinder stuck at 0xc0100210
> Leftover inexact backtrace:
> =======================
> handlers:
> [<c02c5c22>] (usb_hcd_irq+0x0/0x53)
> Disabling IRQ #217
Just as before.
I can't tell you what's causing this to happen, except that it appears to
be some sort of hardware problem. Since it doesn't seem to cause any harm
you could just live with it.
Or, if you're not using any full-speed or low-speed USB devices, you could
simply prevent uhci-hcd from loading at all. Then IRQ 217 wouldn't get
enabled in the first place.
Alan Stern
On Fri, 2006-08-04 at 16:36 +0200, Jesper Juhl wrote:
> >
> > Has this happened more than once?
>
> Seems to happen consistently after ~100000 interrupts.
yap , I remember this same number when I cat /proc/interrupts
On Fri, Aug 04, 2006 at 04:33:11PM +0100, Sergio Monteiro Basto wrote:
> On Thu, 2006-08-03 at 12:08 -0400, Alan Stern wrote:
> > 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
>
> can you explain to me how I mount debugfs filesystem ? please
as root:
mount -t debugfs none /sys/kernel/debug
thanks,
greg k-h
On 04/08/06, Alan Stern <[email protected]> wrote:
> On Fri, 4 Aug 2006, Jesper Juhl wrote:
>
> > On 03/08/06, Alan Stern <[email protected]> wrote:
> > >
> > > Has this happened more than once?
> >
> > Seems to happen consistently after ~100000 interrupts.
> >
> > > 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
> > >
> >
> > # cat /sys/kernel/debug/uhci/0000:00:1d.1
> > Root-hub state: auto-stopped FSBR: 0
> > HC status
> > usbcmd = 0048 Maxp32 CF EGSM
> > usbstat = 0020 HCHalted
> > usbint = 0002
> > usbfrnum = (1)160
> > flbaseadd = 37428160
> > sof = 40
> > stat1 = 0080
> > stat2 = 0080
> > Most recent frame: 458 (88) Last ISO frame: 458 (88)
> >
> >
> > > That will indicate whether the UHCI controller thinks it is sending an
> > > interrupt request.
>
> And it shows that the controller is idle. No IRQ should be pending.
>
> > And just for completenes, here's the backtrace I got just before
> > saving the above info :
> >
> > 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
> > [<c0137b7e>] handle_IRQ_event+0x20/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
> > [<c04cc7fb>] start_kernel+0x173/0x19d
> > [<c0100210>] 0xc0100210
> > DWARF2 unwinder stuck at 0xc0100210
> > Leftover inexact backtrace:
> > =======================
> > handlers:
> > [<c02c5c22>] (usb_hcd_irq+0x0/0x53)
> > Disabling IRQ #217
>
> Just as before.
>
> I can't tell you what's causing this to happen, except that it appears to
> be some sort of hardware problem.
Hmm, the odd thing is that there are no USB devices connected at all.
> Since it doesn't seem to cause any harm
> you could just live with it.
>
> Or, if you're not using any full-speed or low-speed USB devices, you could
> simply prevent uhci-hcd from loading at all. Then IRQ 217 wouldn't get
> enabled in the first place.
>
True, that just seems like a hack...
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Sat, 5 Aug 2006, Jesper Juhl wrote:
> > Just as before.
> >
> > I can't tell you what's causing this to happen, except that it appears to
> > be some sort of hardware problem.
>
> Hmm, the odd thing is that there are no USB devices connected at all.
My guess is that this has nothing to do with the USB controller, other
than the fact that IRQ 217 is enabled because the controller uses it.
Probably the real problem, the unhandled interrupt requests, comes from
some other device entirely.
> > Since it doesn't seem to cause any harm
> > you could just live with it.
> >
> > Or, if you're not using any full-speed or low-speed USB devices, you could
> > simply prevent uhci-hcd from loading at all. Then IRQ 217 wouldn't get
> > enabled in the first place.
> >
> True, that just seems like a hack...
It is. Without knowing the underlying cause of the problem, it's the best
I can suggest.
If you compare /proc/interrupts with earlier versions of the kernel (where
the problem doesn't occur), does it look the same?
Alan Stern
On Fri, 2006-08-04 at 13:11 -0400, Alan Stern wrote:
> On Fri, 4 Aug 2006, Sergio Monteiro Basto wrote:
>
> > > > I also got :
> > > > uhci_hcd 0000:00:10.1: host controller process error, something bad
> > > > happened!
> > > > uhci_hcd 0000:00:10.1: host controller halted, very bad!
> > > > uhci_hcd 0000:00:10.1: HC died; cleaning up
> > > > usb 3-2: USB disconnect, address 2
> > > >
> > > > > 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
> > > >
> > > > can you explain to me how I mount debugfs filesystem ? please
> > >
> > > You don't need debugfs to solve the problem shown above.
> > >
> > > What version of the kernel are you using?
> > >
> > > Alan Stern
> >
> > http://bugme.osdl.org/show_bug.cgi?id=6419#c16
> > http://bugme.osdl.org/show_bug.cgi?id=6419#c19
> > all the time, with 2.6.18-rc3
>
> Here is a patch which should fix the "host controller process error"
> problem:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=115435540308759&w=2
>
yes! I am testing 2.6.18-rc3-git7.bz2 which have your patch, with
CONFIG_USB_DEBUG and CONFIG_DEBUG_FS on and I can googling :), it is
working. I have done a stress test with azureus and still working!
Tomorrow I will test the irq 201, 209 or 217 nobody care.
Many thanks Alan,
--
S?rgio M. B.
my system is much different, but I got similar problems
http://bugme.osdl.org/show_bug.cgi?id=6419#c17
irq 201: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[<ffffffff8026a20a>] dump_stack+0x12/0x17
[<ffffffff802b6c26>] __report_bad_irq+0x30/0x7d
[<ffffffff802b6e46>] note_interrupt+0x1d3/0x219
[<ffffffff802b6383>] __do_IRQ+0xc8/0x107
[<ffffffff8026b166>] do_IRQ+0xe7/0xf5
[<ffffffff8025d189>] ret_from_intr+0x0/0xa
DWARF2 unwinder stuck at ret_from_intr+0x0/0xa
Leftover inexact backtrace:
<IRQ> <EOI> [<ffffffff80230d50>] unix_poll+0x0/0x99
[<ffffffff802569ed>] mwait_idle+0x36/0x4a
[<ffffffff8024888d>] cpu_idle+0x95/0xb8
[<ffffffff806da842>] start_kernel+0x220/0x225
[<ffffffff806da28a>] _sinittext+0x28a/0x28e
handlers:
[<ffffffff880eaaf5>] (rhine_interrupt+0x0/0xae3 [via_rhine])
Disabling IRQ #201
root@monteirov:~#cat /proc/interrupts
CPU0 CPU1
0: 356842 312644 IO-APIC-edge timer
1: 586 711 IO-APIC-edge i8042
6: 5 0 IO-APIC-edge floppy
7: 2 0 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 33214 32075 IO-APIC-edge i8042
15: 11161 11127 IO-APIC-edge ide1
193: 65857 9444 IO-APIC-level libata
201: 100000 0 IO-APIC-level eth0
^^^^^^
209: 91593 91062 IO-APIC-level uhci_hcd:usb1,
uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb5
217: 1151 538 IO-APIC-level VIA8237
225: 49661 49438 IO-APIC-level nvidia
NMI: 438 403
LOC: 669481 669457
ERR: 0
MIS: 0
On Fri, 2006-08-04 at 16:36 +0200, Jesper Juhl wrote:
> On 03/08/06, Alan Stern <[email protected]> wrote:
> >
> > Has this happened more than once?
>
> Seems to happen consistently after ~100000 interrupts.
>
> > 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
> >
>
> # cat /sys/kernel/debug/uhci/0000:00:1d.1
> Root-hub state: auto-stopped FSBR: 0
> HC status
> usbcmd = 0048 Maxp32 CF EGSM
> usbstat = 0020 HCHalted
> usbint = 0002
> usbfrnum = (1)160
> flbaseadd = 37428160
> sof = 40
> stat1 = 0080
> stat2 = 0080
> Most recent frame: 458 (88) Last ISO frame: 458 (88)
>
>
> > That will indicate whether the UHCI controller thinks it is sending an
> > interrupt request.
> >
>
> And just for completenes, here's the backtrace I got just before
> saving the above info :
>
> 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
> [<c0137b7e>] handle_IRQ_event+0x20/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
> [<c04cc7fb>] start_kernel+0x173/0x19d
> [<c0100210>] 0xc0100210
> DWARF2 unwinder stuck at 0xc0100210
> Leftover inexact backtrace:
> =======================
> handlers:
> [<c02c5c22>] (usb_hcd_irq+0x0/0x53)
> Disabling IRQ #217
>
>