[OpenBIOS] [PATCH] OBP Memory deallocation

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Feb 11 21:19:58 CET 2014


On 11/02/14 00:44, Olivier Danet wrote:

> I knew you would not like that ...
>
> Allocation :
> - In the current code, 'arch/sparc32/lib.c:obp_memalloc(va,size,align)'
> always calls
> ofmem_claim_virt(va,size,align) with align=0. So allocating with va=0
> does not work.
>
> IIRC, there was also a problem ensuring that the physical and virtual
> areas had the
> same size and alignment.
>
> Deallocation :
>
> Here is a log of NextStep booting the ISO, with these crazy patches and
> this option in OpenBIOS :
> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="true"/>
> and "#define CONFIG_DEBUG_MEM" in arch/sparc32/lib.c
> ... and a few manual linefeeds

(big cut)

> The big problem is in :
> obp_dumb_memfree: virta 0xf0180000, sz 4120576 (=0x3EE000)
>
> No memory starting at 0xf0180000 was ever allocated!
> There is instead something at 0xf016e000, sz 4194304 (0x400000)
>
> There is certainly a relation, as the end match :
> f016e000+400000 = F056E000
> f0180000+3EE000 = F056E000
>
> I tried a bit to trace Sun's OFW with gdb, but with no luck.
> I don't know whether it is a bug in OpenBIOS, QEMU or NextSTEP.
> It certainly does not look reasonable...

Thanks for the traces - these are really helpful! :)  First thing to 
check is, are these traces from an unpatched SVN trunk? For example your 
output looks like this:


obp_memalloc: virta 0xf016e000, sz 4194304, align 4
OFMEM: ofmem_claim phys=ffffffffffffffff size=00400000 align=00000004
OFMEM: ofmem_claim_virt virt=f016e000 size=00400000 align=00000004
OFMEM: ofmem_claim_virt virt=f016e000 size=00400000 align=00000000
OFMEM: ofmem_map_page_range f016e000 -> 0069c0000 00400000 mode 000000bc


According to obp_memalloc(), ofmem_claim_virt() should only be called 
once whereas in these traces it is being called twice?


ATB,

Mark.



More information about the OpenBIOS mailing list