[OpenBIOS] memory corruption with "read" $call-method (sparc32)

[Mark Cave-Ayland]

Artyom Tarasenko wrote:

> Yes, it's a bunch of reads.  The first 9 reads (f00890ec-f00a10ec) don't
>  do any visible harm, but  f00a30ec is lethal. Under OBP there is more
> than 30 reads after this point. Didn't count them after this point.

Well given that the same disk code for SPARC64 is reading in several 
megs at a time without any problems now, I think if there was an issue 
then it could be in one of the hardware drivers or possibly the MMU.

Wait a minute. I've just noticed that arch/sparc32 hasn't been updated 
to use the new libopenbios/ofmem_common.c API which will handle the 
physical memory allocation, virtual memory allocation and mappings for 
you. And this would explain why CONFIG_DEBUG_OFMEM wouldn't have 
actually output anything :(

I'd suggest a good starting point for you would be to first switch over 
to the libopenbios/ofmem_common.c API in arch/sparc32/lib.c using 
arch/sparc64/lib.c as a reference, and then similarly update 
arch/sparc32/romvec.c where appropriate. I also seem to recall that Blue 
had a compile time #define in Qemu that would dump the page table 
contents and so you can use this to verify that the OpenBIOS code is 
correct. With these two things in place, then you have all the debugging 
information you need :D


HTH,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs