Am 22.12.2010 um 11:49 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
While I'm not against reversing the direction, your above statement worries me. Our claim code should only claim free memory. So either the respective boot loader doesn't actually claim the memory it's using (the recent ppc bug that broke Haiku), or there's a bug in ofmem that you're hiding by this change. Both directions should in theory work, I believe.
Okay - having played with this a bit further, it seems that it's the physical memory allocations that need to be reversed in order to prevent my Solaris 8 kernel from crashing mid-boot. Below is the log from my OFMEM-enabled SPARC32 OpenBIOS booting Solaris 8 with physical memory allocated from the bottom upwards:
[...]
OFMEM: ofmem_claim phys=ffffffffffffffff size=00018000 align=00000008 OFMEM: ofmem_claim phys returned 000135000 OFMEM: ofmem_claim_virt virt=f025d000 size=00018000 align=00000000 OFMEM: ofmem_map_page_range f025d000 -> 000135000 00018000 mode 000000bc
(hangs at this point)
The Solaris boot loader appears to be claiming specific virtual addresses, but claiming the physical addresses from the pool. The last physical address allocated from the pool before the crash is 0x135000 which I think may be overwriting the kernel itself as I have something in the back of my mind that says the kernel is loaded at 0x100000 - Blue any ideas?
As a general piece of advice I would suggest to turn on debugging for the CIF. I would assume that the client simply calls "claim", then something might be wrong with the mapping to ofmem. Or Solaris makes specific assumptions, which Tarl might be able to answer. Maybe you need to claim specific parts of memory during initial setup so that they are exempt.
Andreas