On Mon, Oct 18, 2010 at 7:43 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Artyom Tarasenko wrote:
Does this sound reasonable? I'm surprised that one else has realised that the obp_fortheval_v2 function signature was wrong, but I guess it probably hardly gets used for anything these days.
Ops. Forgot to submit this patch back then. :(. Sorry. The reason was not getting too far with the patch, because of the broken memory management.
Okay; I've committed something which should do the trick to SVN as r915.
Hmmmm these symptoms look exactly like something on SPARC64 where various bits of memory were getting clobbered because of a lack of stack space... (goes and has a look)...
Right - it's definitely something related to the stack when calling from the client into OpenBIOS (or vice-versa). If you take a look at arch/sparc32/context.c and start increasing IMAGE_STACK_SIZE, say to 16K or 32K you'll see that things suddenly start to work much better.
I think its related to the flushing of register windows onto the stack when switching between the two. My thoughts are that this is probably related to Igor's SPARC64 patches here:
http://www.openfirmware.info/pipermail/openbios/2009-July/003762.html
I suspect that you'll need to come up with something along similar lines for SPARC32. Blue, any thoughts?
On Sparc32 the client interface is not used and there is no 'flushw' instruction, but otherwise saving and restoring %g registers and flushing windows may be helpful.