From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> Date: Mon, 5 May 2008 17:06:51 -0400 (EDT) From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> Date: Mon, 5 May 2008 17:06:51 -0400 (EDT) > On Mon, 5 May 2008, David Miller wrote: > > > > Call Trace: > > > [000000000058bda8] __handle_sysrq+0xd0/0x1a0 > > > [0000000000592500] sunsu_serial_interrupt+0x4e8/0x6c0 > > > [000000000047dd4c] handle_IRQ_event+0x34/0xa0 > > > [000000000047f2dc] handle_fasteoi_irq+0x64/0xe0 > > > [000000000042d548] handler_irq+0x70/0xa0 > > > [00000000004208b4] tl0_irq5+0x1c/0x20 > > > [0000000000404980] __handle_softirq+0x8/0x10 > > > [000000000045d9e0] run_timer_softirq+0x188/0x200 > > > [00000000004590e4] __do_softirq+0x6c/0xe0 > > > [00000000004591b8] do_softirq+0x60/0x80 > > > [0000000000459344] irq_exit+0x6c/0xa0 > > > [000000000042d558] handler_irq+0x80/0xa0 > > > [00000000004208b4] tl0_irq5+0x1c/0x20 > > > [fffff8006e147619] 0xfffff8006e147621 > > > [000000001001d638] usb_hcd_poll_rh_status+0x40/0x180 [usbcore] > > > [000000001001dafc] usb_add_hcd+0x384/0x5c0 [usbcore] ... > Maybe the interrupt happened before interrupts were disabled. Or maybe > interrupts aren't getting disabled the way they should. The stack dump > seems to indicate that an IRQ5 occurs nested within another IRQ5; that > shouldn't be possible. Interrupts are reenabled when running softirqs right before returning from the top-level interrupt. Lo' and behold, the nested interrupt occurs in the middle of run_timer_softirq() :-) Nothing is wrong with the backtrace nor sparc64 interrupt handling. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
