Corey, On Fri, Dec 19, 2008 at 1:26 AM, Corey Ashford <cjash...@linux.vnet.ibm.com> wrote: > > I think you were pretty close to putting your finger on the problem. After > stepping through the code, I see that it is looping, and I believe I know > what the problem is. When CONFIG_PERFMON is defined, we call > pfm_handle_work before do_signal. But the problem is that the second > parameter to do_signal is initialized in the code that precedes these two > calls. The second parameter is passed in r4, and in the case of having > CONFIG_PERFMON turned on, we end up changing the value of r4 in the process > of calling pfm_handle_work. Depending on the changed value of r4, it can > cause an infinite looping problem. > > As an experiment, I reversed the two calls, so that pfm_handle_work occurs > after do_signal, and so that r4 is still valid. This allowed the kernel to > boot up even with CONFIG_FUNCTION_TRACER enabled. > > My question to you is: is it ok to call do_signal before pfm_handle_work, or > must it be done in the other order? > Looking at the x86 code, pfm_handle_work() is called before but this should not really matter. pfm_handle_work() is not posting signals.
------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
