Corey, It looks like you have an interrupt masking issue. You should not get into the interrupt handler while executing in schedule. Do this happen when you do get into a resend_irq situation or when you're not?
On Sat, May 10, 2008 at 1:55 AM, Corey Ashford <[EMAIL PROTECTED]> wrote: > Hello Stephane, > > While trying to test my implementation of resend_irq for POWER, I ran > into a perfmon2 problem, I think. > > In order to increase the number of PMU interrupts I'm getting, I decided > to start with a PAPI C test case "first.c" and modify it so that it > records both user and kernel domain, and adds a call to PAPI_overflow to > set the threshold on PAPI_TOT_CYC to 1 million so that I'd get about > 2000 PMU interrupts per second (2 GHz processor) just as a starting point. > > The overflow handler passed to PAPI_overflow() does nothing other than > print a count of overflows received every 1000 counts. > > Well, I can run this test case to completion sometimes, but fairly often > it will hang in the kernel with a stack trace similar to this: > > 3:mon> c0 > 0:mon> t > [c00000002e32eef0] c0000000004b18d4 ._spin_lock+0x5c/0x88 > [c00000002e32ef70] c00000000004991c .task_rq_lock+0x68/0xcc > [c00000002e32f010] c000000000049b48 .try_to_wake_up+0x40/0x1c0 > [c00000002e32f0d0] c000000000062758 .signal_wake_up+0x48/0x74 > [c00000002e32f160] c000000000062a88 .__group_send_sig_info+0xa8/0xcc > [c00000002e32f200] c0000000000631fc .group_send_sig_info+0x64/0xa0 > [c00000002e32f2b0] c0000000000eca24 .send_sigio+0x124/0x1f0 > [c00000002e32f3f0] c0000000000ecb5c .__kill_fasync+0x6c/0xa0 > [c00000002e32f480] c0000000000ecbec .kill_fasync+0x5c/0x94 > [c00000002e32f520] c00000000024d6c4 .pfm_notify_user+0xd4/0xf0 > [c00000002e32f5a0] c00000000024d850 .pfm_ovfl_notify+0x170/0x198 > [c00000002e32f640] c00000000024b314 .pfm_interrupt_handler+0xbec/0xf9c > [c00000002e32f7b0] d0000000000e82f4 .pfm_power5_irq_handler+0x40/0x80 > [perfmon_power5] > [c00000002e32f840] c000000000043dbc .powerpc_irq_handler+0x60/0x78 > [c00000002e32f8c0] c000000000023488 .performance_monitor_exception+0x38/0x50 > [c00000002e32f940] c000000000003d80 performance_monitor_common+0x100/0x180 > --- Exception: f00 (Performance Monitor) at c000000000045e38 > .__enqueue_entity+0 > x3c/0xb8 > [c00000002e32fcb0] c00000000004e5e8 .put_prev_task_fair+0x74/0x98 > [c00000002e32fd40] c0000000004af708 .schedule+0x46c/0x768 > [c00000002e32fe30] c000000000008c54 do_work+0x14/0x34 > --- Exception: 901 (Decrementer) at 0000000010001ff8 > SP (ffffd320) is in userspace > > > So what we have here is that spin_lock is getting called in the context > of schedule(). That doesn't seem good to me, but I'm am not wise enough > in the ways of the Linux kernel. Do you think this should work correctly? > > To make forward progress on resend_irq, I'm going to switch away from > using an overflow handler to a sampler test case, so this shouldn't stop > my progress, it will just slow me down a bit. > > Regards, > > - Corey > > -- > Corey Ashford > Software Engineer > IBM Linux Technology Center, Linux Toolchain > Beaverton, OR > 503-578-3507 > [EMAIL PROTECTED] > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > perfmon2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ perfmon2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
