On May 5, 2009, at 7:42 PM, Morrison, Tom wrote:
The test case we found is under 'extreme' duress (intense loading on an MPC8572)...with many applications.... using A LOT of SPE instructions... ---- If you look at the context switch code (in latest code entry_32.S), I believe the context switch performs a SAVE_NVGPR() - which in our interpretation (in ppc_asm.h) - only saves the lower 32 bits of the GPR (stw/lwz)... This is only a guess of where the problem lies - based upon the single SPE instruction that seemingly got misinterpreted, and shifts the data By '1 byte' (and this code gets executed successfully MANY more times at lower bandwidths - than failures seen at higher bandwidths)... ---- I am not sure how to proceed...we know how to recreate with our application, but we would love to know how to change (safely) the pt_regs to "long long" for the GPRs and then safely move all 64bits of each GPR into these doubles... We could then re-test and see if this helps? Tom
If you use SPE in an application the full 64-bits are saved and restored it just split into two locations (one for the lower 32-bits and one for the upper 32-bits).
Look at load_up_spe and giveup_spe in arch/powerpc/kernel/ head_fsl_booke.S
On the 8572 are you running w/SMP? What kernel version are you using if so? Do you see the same issue on the MPC8548?
- k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
