[okl4-developer] roottask error. any ideas?

[Jorge Torres]

Hi,


I think it has to do with python, on your centos 5 installation,

Cheers,

Jorge





On Feb 19, 2008 10:15 PM, Boy Dfx <boy3dfx2 at yahoo.com> wrote:

> Hello.
>
> I'm getting back to you for some help or thoughts regarding the following
> situation.
>
> I have installed OKL4 under a number of different Linux OS-es, by always
> using arm-linux-3.4.4 crosscompiler from the nicta site, and a proof
> version of skyeye (a version that worked on a verified image.sim).
>
> Sometimes, the build just works from the beginning (I can enter busybox
> and play around with my gumstix simulated system) and sometimes it crashes
> with a roottask page fault (like in the following lines). The roottask error
> changes in different instalations. It can be that one PC running a linux
> distro works and another using  matching hardware does not.
>
> I might have left out some packages from time to time at instalation time,
> but nothing really essential (like gcc, python or anything corelated
> through,etc). Example: Centos 5 - working, Centos 5 - not working, Fedora
> core 4 -working, Fedora Core 3  -working, openSUSE - working.
>
> I just want to understand what is the source for this particular problem.
> By doing some cross-checking I can tell you it is not a skyeye problem. If I
> have 2 systems with the same hardware, one with l4 working and one without,
> if I load the image.sim from the working build into both skyeye instances
> then the simulation works.
>
> Somehow the image.sim gets corrupted either by some x86 code being loaded
> into it or by an executable taking precedence over another, or something not
> created during the build.
>
> The PATH variable modification is the same, folder instalations the same
> (I install arm-linux-gcc in the same folder and tar -xvzf the same way).
>
> Can you think of a package or some enviromental variable that when missing
> can cause this kind of behaviour?
>
> Initially I thought there was a bug in File Roller that was fixable by
> always using tar. That is because I noticed that in some systems (like FC3,
> FC4) File Roller refused to create tools/cust and other empty folders in
> okl4 directory and arm-linux-3.4.4 directory. I thought I got to the
> bottom of this (and also sent you an email to warn other people about this
> potential problem and how to stay away), because simply using tar solved my
> problem. Until when the tar solution did not work on a CentOS5 instalation.
> It is not python or gcc version related because on a similar machine it
> does.
>
> What I use for my builds in general:
> python 2.4.4 (except on CentOS 5 where I use python 2.4.3)
> gcc
> arm-linux-3.4.4 (ffrom NICTA)
> skyeye-1.2.4 (built with make NO_DBCT=1 NO_BFD=1)
> skyeye-1.2.3 (built with make NO_DBCT=1 NO_BFD=1 STATIC=1 NO_LCD=1
> PPC_DISABLED=1)
>
>
> Listing of the error.
>
> skyeye -c /proj/okl4_release_1.5.2/tools/sim_config/gumstix.skyeye -e
> /proj/okl4_release_1.5.2/build/images/image.sim
> big_endian is false.
> arch: arm
> cpu info: xscale, pxa25x, 69052100, fffffff0, 2
> mach info: name pxa_lubbock, mach_init addr 0x8060fa0
> uart_mod:0, desc_in:, desc_out:, converter:
> SKYEYE: use xscale mmu ops
> start addr is set to 0xa0000000 by exec file.
>
> OKL4 - (provider: Open Kernel Labs) built on Feb 19 2008 17:52:17 using
> gcc version 3.4.4.
>
>  *****************************************
>  *  Iguana system, Copyright 1996-2006   *
>  *  ERTOS - National ICT Australia       *
>  *****************************************
>
> vbase is 0xa4000000, vend is 0xcfffffff
> addr is 0xa4000000, vbase is 0xa4000000
> roottask read pagefault at 0000001c, ip=800038bc - deny
> --- KD# roottask pagefault  ---
> >
>
>
> ------------------------------
> Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080219/1e4fd501/attachment.htm