[OpenBIOS] Sparc64 memory allocation problem

Blue Swirl blauwirbel at gmail.com
Tue Aug 24 21:50:29 CEST 2010


On Tue, Aug 24, 2010 at 12:33 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Blue Swirl wrote:
>
>> Here's last lines from OpenBSD 4.3 boot, with DEBUG_CIF enabled:
>>
>> Booting cdrom:f/bsd
>> 2590536 at 0x1000000of_client_interface: call-method 80aec8 ffe880f8 0
>> 278748 1000000
>> call-method claim ([5] -- [2])
>> handle_calls return: 0 1000000
>> of_client_interface: call-method 80aec8 ffe88838 400000 278748
>> call-method claim ([4] -- [3])
>> handle_calls return: 0 0 400000
>> of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff
>> 278748 1000000 0 400000
>> call-method map ([7] -- [1])
>> handle_calls return: 0
>> of_client_interface: call-method 80aec8 ffe880f8 2000 4000
>> call-method claim ([4] -- [2])
>> handle_calls return: 0 2001e000
>> of_client_interface: call-method 80aec8 ffe88838 2000 4000
>> call-method claim ([4] -- [3])
>> handle_calls return: 0 0 1e000
>> of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000
>> 2001e000 0 1e000
>> call-method map ([7] -- [1])
>> handle_calls return: 0
>> +3236576 at 0x1800000of_client_interface: call-method 80aec8 ffe880f8 0
>> 400000 1800000
>> call-method claim ([5] -- [2])
>> handle_calls return: 0 1800000
>> of_client_interface: call-method 80aec8 ffe88838 400000 400000
>> call-method claim ([4] -- [3])
>> handle_calls return: 0 0 800000
>> ^ badness, mem_claim returns 0x800000
>> of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff
>> 400000 1800000 0 800000
>> call-method map ([7] -- [1])
>> handle_calls return: 0
>> Unhandled Exception 0x0000000000000010
>> PC = 0x0000000000803e20 NPC = 0x0000000000803e24
>> Stopping execution
>>
>> The client executes near 0x800000. However, the ofmem_claim_phys()
>> (called from mem_claim() in lib.c) will happily allocate and return
>> that range. BSD loader then crashes because it tries to zero the BSS
>> which will be at 0x800000 and zeroing reaches PC value.
>
> Hmmm. It's probably worth turning off auto-boot? and sticking a breakpoint
> in /openprom/client-services on the call-method method - you can then use
> the debugger to use ihandle>phandle and work out which memory nodes the
> methods are being invoked on by cross-referencing with the output of
> show-devs.
>
> Also, from the trace above it doesn't look as if you built with
> CONFIG_DEBUG_OFMEM which should give more information about how the physcial
> and virtual memory ranges are allocated.
>
>> Here's the loader code:
>>
>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/elf64_exec.c?rev=1.1
>>
>> Maybe some memory allocation method (FCode?) still does not use ofmem.
>
> I'm fairly sure everything in SPARC64/PPC does. SPARC32 really should be
> converted over too, one day...

The problem was that ELF loader didn't allocate the areas. Now with
r858 OpenBSD gets into kernel:
Loading FCode image...
Loaded 4893 bytes
entry point is 0x4000
OpenBSD IEEE 1275 Bootblock 1.1
..
Jumping to entry point 0000000000800000 for type 0000000000000001...
switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
>> OpenBSD BOOT 1.2
Trying bsd...
Booting cdrom:f/bsd
2590536 at 0x1000000+3236576@0x1800000+957728 at 0x1b162e0
symbols @ 0x200241c0 36 start=0x1000000
CHAINprom_get_msgbuf: test failed
prom_get_msgbuf: allocated new buf at ffffffff
prom_get_msgbuf: claiming new buf at ffffffff
Unhandled Exception 0x0000000000000032
PC = 0x0000000001080bc4 NPC = 0x0000000001080bc8
Stopping execution

I noticed that MilaX had problems with allocation happening, so I made
the loader ignore the failures. That is probably not correct.



More information about the OpenBIOS mailing list