[okl4-developer] Roottask pagefault at 00000000

[Ihor Kuz]

Hi Lukas,

This is what happens if you use an 'old' version of skyeye (i.e. the  
one on the ERTOS site and recommended in the OKL4 README).  Try using  
version 1.2.3 or greater and see how it goes.

BTW, when building 1.2.3 use: make NO_DBCT=1 NO_BFD=1 STATIC=1  
NO_LCD=1 PPC_DISABLED=1
When building 1.2.4 use: make NO_DBCT=1 NO_BFD=1

Ihor

-- 
Ihor Kuz
Researcher

NICTA | Locked Bag 6016 | UNSW, Sydney NSW 1466
T + 61 2 8306 0582 | F +61 2 8306 0406
www.nicta.com.au l ihor.kuz at nicta.com.au




On 18/03/2008, at 3:28 , Lukas HANEL wrote:

> Hi everybody
>
> I want to play around with OKL4 and downloaded the current snapshot  
> (1.5.2) together with the skyeye simulator and the arm-compiler  
> from the ERTOS prebuild binaries page. (http://ertos.nicta.com.au/ 
> software/prebuilt/binaries.pml)
> Using the following commandline I ran into a roottask pagefault at  
> 00000000.
>  ~/okl4_release_1.5.2$ ./tools/build.py machine=gumstix  
> project=iguana example=naming simulate
>
> Listing of the problem:
>
> skyeye -c tools/sim_config/gumstix.skyeye -e /home/lukas/ 
> okl4_release_1.5.2/build/images/image.sim_nobits
> arch: arm
> cpu info: xscale, pxa25x, 69052100, fffffff0, 2
> mach info: name pxa_lubbock, mach_init addr 0x805f300
> SKYEYE: use xscale mmu ops
>
> OKL4 - (provider: Open Kernel Labs) built on Mar 17 2008 12:22:43  
> using gcc version 3.4.4.
> roottask read pagefault at 00000000, ip=80007cd4 - deny
> --- KD# roottask pagefault  ---
> > showtcbext
> tcb/tid/name [current]: current
> === roottask == TCB: e000af80 == ID: 001d4001 = d0001f00/d0001f00  
> == PRIO: 0xff ===
> UIP: 80007cd4   queues: Rswl      space: f0105f00/0
> USP: 00000000   tstate: RUNNING   ready: roottask:roottask   pdir :  
> f0108e0c
> sndhd : NIL_THRD  send : NIL_THRD:NIL_THRD   pager: NIL_THRD
> total quant:    0x0 us, ts length  :       0x2710 us, curr ts:  
> 0x2710 us
> resources:    00000000 [ek], ARM [PID: 0, vspace: 0, domain: 15,  
> dom_mask 40000001]
> continuation: f000e31c   preemption_cont: 00000000
> scheduler: roottask    exception_handler: NIL_THRD
>   partner: NIL_THRD        saved partner: NIL_THRD      saved  
> state: RUNNING
>
> user handle:          00000000  cop flags:           00           
> preempt flags: 00 [~]
> incoming notify bits: 00000000  notify mask:         00000000    
> virtual sender: NIL_THRD
> last preempted_ip:    00000000  preempt_callback_ip: 00000000
>
> mr( 0): 00000000 00000000 00000000 00000000 00000000 00000000  
> 00000000 00000000
> mr( 8): 00000000 00000000 00000000 00000000 00000000 00000000  
> 00000000 00000000
> mr(16): 00000000 00000000 00000000 00000000 00000000 00000000  
> 00000000 00000000
> mr(24): 00000000 00000000 00000000 00000000 00000000 00000000  
> 00000000 00000000
> Message Tag: 0 untyped, label = 0, flags = ---
>
> Acceptor: 00000000 (a)  Error code: 0
>
>
> arm-linux-objdump -dS build/iguana_server/bin/ig_server:
> static inline void idl4_set_no_response(idl4_server_environment *ev)
> {
>   ev->_action = IDL4_NO_RESPONSE;
> 80007ccc:       03e03000        mvneq   r3, #0  ; 0x0
> 80007cd0:       05863000        streq   r3, [r6]
> 80007cd4:       e8bd80f0        ldmia   sp!, {r4, r5, r6, r7, pc}
>
> 80007cd8 <iguana_eas_create_thread_impl>:
>         idl4_set_no_response(_env);
>     }
>     return;
> }
>
> For me it looks like a faulting stack access because of a not  
> initialized stack pointer.
>
>
> I thought it might be related to the following problem already  
> reported in the mailinglist:
> [okl4-developer] roottask error. any ideas?
> http://lists.okl4.org/pipermail/developer/2008-February/000649.html
>
> I am however not sure how to apply this proposed solution:
>> Hi Ryan, On 21/02/2008, at 3:56 PM, Ryan Heffernan wrote: > It  
>> looks like the nobits section is indeed filled with garbage. I'm >  
>> pretty new to OKL4 so you'll have to forgive me for asking the  
>> best > way > to go about manually zeroing the bss... should I add  
>> my own function > to > the ARM init.cc and call it from  
>> startup_system? Try # ./tools/pyelf/elfweaver modify -o TARGET.elf  
>> SOURCE.elf -- remove_nobits -- (nt) Nelson Tam nelson at ok-labs.com
> Which elf files should be modifed?
> And after modifing them, wouldn't they be deleted/rebuild by the  
> build-system?
> At least after changing their sources. So how could this task be  
> automated?
> Where in the build-scripts could one add this line?
>
> Could you please give me some hints how to solve this problem!
>
> Lukas Hänel
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer