Timothy Pearson <[email protected]> writes: > ... > > So a little more detail on this, just to put it to rest properly vs. > assuming hand analysis caught every possible pathway. :) > > The debugging that generates this stack trace also verifies the following in > __giveup_fpu(): > > 1.) tsk->thread.fp_state.fpr doesn't contain the FPSCR contents prior to > calling save_fpu() > 2.) tsk->thread.fp_state.fpr contains the FPSCR contents directly after > calling save_fpu() > 3.) MSR_FP is set both in the task struct and in the live MSR. > > Only if all three conditions are met will it generate the trace. This > is a generalization of the hack I used to find the problem in the > first place. > > If the state will subsequently be reloaded from the thread struct, > that means we're reloading the registers from the thread struct that > we just verified was corrupted by the earlier save_fpu() call. There > are only two ways I can see for that to be true -- one is if the > registers were already clobbered when giveup_all() was entered, and > the other is if save_fpu() went ahead and clobbered them right here > inside giveup_all(). > > To see which scenario we were dealing with, I added a bit more > instrumentation to dump the current register state if MSR_FP bit was > already set in registers (i.e. not dumping data from task struct, but > using the live FPU registers instead), and sure enough the registers > are corrupt on entry, so something else has already called save_fpu() > before we even hit giveup_all() in this call chain.
Can you share the debug patch you're using? cheers
