init (busybox) problem on OSK5912

init (busybox) problem on OSK5912

[Eduardo Gallofin]

Hi,

   I have just ported the 2.6.16 kernel to the OSK and
it works fine together with the rootfs available at
the omap website. However, i tried compiling busybox
(1.00 and 1.1.2) for OMAP and used it, but the OSK
seems to hang up after "Freeing init memory: 120K".

   Do you have any ideas where it might have gone
wrong?

  Thanks.

Ed

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

init (busybox) problem on OSK5912

[Eduardo Gallofin]

I'm replying to my own query to give update ....

I managed to have init working by using an older
version of busybox (1.00-pre8), however another
problem happens with /bin/sh (ash) crashing and
restarting over and over.

The problem seems to happen only when busybox is
compiled with shared libraries. other busybox applets
(like ls -l) also terminate with segmentation fault.
strace shows that they seg fault when connecting or
binding to a socket.

any thoughts why these only happen with shared
libraries?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

init (busybox) problem on OSK5912

[Eduardo Gallofin]

Hello Chetan,

   You can do a "make menuconfig" on the busybox
source directory to use the GUI-like configuration
tool. Select <build options> and select <Build busybox
as a static library>. Save the configuration and
compile.

  To check if your busybox program is linked
statically, you can do a "file busybox" on your linux
machine and see the file attributes. It should show
"statically linked".

  The /lib and /usr/local/lib folders are already part
of the basefs, and having busybox as statically linked
doesn't affect these folders. Although when you
compile your programs statically, you won't be needing
the library files.

   Hope this helps. I really would like to compile all
my apps dynamically since this would save a great deal
of disk space, especially when you have multiple apps
sharing the same libraries. Statically compiled
programs are huge!!! 

- Ed



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: init (busybox) problem on OSK5912

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Hi Eduardo,

On 04/05/06, Eduardo Gallofin <egallofin@yahoo.com> wrote:
> I'm replying to my own query to give update ....
>
> I managed to have init working by using an older
> version of busybox (1.00-pre8), however another
> problem happens with /bin/sh (ash) crashing and
> restarting over and over.
>
> The problem seems to happen only when busybox is
> compiled with shared libraries. other busybox applets
> (like ls -l) also terminate with segmentation fault.
> strace shows that they seg fault when connecting or
> binding to a socket.
>
> any thoughts why these only happen with shared
> libraries?
From your description it sounds like a similar bug to what we've been
facing on some PDAs based on OMAP311. If it is the same thing, then it
doesn't matter what version of busybox or other applications you are
running or whether it's compiled statically. All programs seem to be
affected by the bug in the way that they hang or segfault in random
places. Statically compiled programs do that with lower probability
but they still do. Some versions are more affected and others less,
but changing a single line in the busybox code changes that
probability randomly.

We haven't found a definitive solution yet but we found a nasty
workaround (credits go to nasty Marex): compile the kernel with swap
support ("Paging of anonymous memory" in the config, I think) -- you
don't need to add swap partitions, just compile the kernel with this
option enabled. This should lower the probability of breakage to near
acceptable level. It would be interesting to see if this works for you
and if it's really the same problem. So far I was only seeing it on
OMAP311. It might just as well be something totally different, in this
case just ignore me.

With this option enabled we're able to run whole dynamically-linked
Linux distributions including X, Gnome, KDE, gdb and strace. The
problem persists but is a whole order of magnitude less annoying.

BTW: programs compilled statically against uclibc are not huge at all,
sometime smaller than dynamically-linked against glibc.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
Good luck!

Regards,
Andrzej
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

init (busybox) problem on OSK5912

[Eduardo Gallofin]

Hi Andrzej,

   Thanks for your response. However, we already have
swap support enabled all the time, but still the
problem persists. And it does not seem random at all,
our applications always fail with a segfault when
connecting or binding to a socket....

   I'm using the tool chain available at the
linux.omap website (3.3.2).... I've tried 3.4.1 but I
still have the same problem... do you have a link to
the newest toolchain (binaries please). It might be
worth a try... 

   Thank you very much!

- Ed -



--- andrzej zaborowski <balrog@zabor.org> wrote:

> Hi Eduardo,
> 
> From your description it sounds like a similar bug
> to what we've been
> facing on some PDAs based on OMAP311. If it is the
> same thing, then it
> doesn't matter what version of busybox or other
> applications you are
> running or whether it's compiled statically. All
> programs seem to be
> affected by the bug in the way that they hang or
> segfault in random
> places. Statically compiled programs do that with
> lower probability
> but they still do. Some versions are more affected
> and others less,
> but changing a single line in the busybox code
> changes that
> probability randomly.
> 
> We haven't found a definitive solution yet but we
> found a nasty
> workaround (credits go to nasty Marex): compile the
> kernel with swap
> support ("Paging of anonymous memory" in the config,
> I think) -- you
> don't need to add swap partitions, just compile the
> kernel with this
> option enabled. This should lower the probability of
> breakage to near
> acceptable level. It would be interesting to see if
> this works for you
> and if it's really the same problem. So far I was
> only seeing it on
> OMAP311. It might just as well be something totally
> different, in this
> case just ignore me.
> 
> With this option enabled we're able to run whole
> dynamically-linked
> Linux distributions including X, Gnome, KDE, gdb and
> strace. The
> problem persists but is a whole order of magnitude
> less annoying.
> 
> BTW: programs compilled statically against uclibc
> are not huge at all,
> sometime smaller than dynamically-linked against
> glibc.
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source@linux.omap.com
> >
>
http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
> Good luck!
> 
> Regards,
> Andrzej
> --
> balrog 2oo6
> 
> Dear Outlook users: Please remove me from your
> address books
>
http://www.newsforge.com/article.pl?sid=03/08/21/143258
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: init (busybox) problem on OSK5912

[Eduardo Gallofin]

Just want to give some updates on my case...

I run strace with the "segfaulting" program (./strace
ls -l) and here the trace I see...

/ # /root/./strace ls -l
execve("/bin/ls", ["ls", "-l"], [/* 7 vars */]) = 0
brk(0)                                  = 0x3b000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT
(No such file or directory)
open("/usr/local/arm/3.3.2/etc/ld.so.cache", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/v5l/fast-mult/half/libm.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/v5l/fast-mult/half",
0xbeadd2e4) = -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/v5l/fast-mult/libm.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/v5l/fast-mult",
0xbeadd2e4) = -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/v5l/half/libm.so.6",
O_RDONLY) = 3
read(3,
"\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\270:\0\000"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1909672,
...}) = 0
old_mmap(NULL, 497348, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 3, 0) = 0x4001f000
mprotect(0x40091000, 30404, PROT_NONE)  = 0
old_mmap(0x40097000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x70000) = 0x40097000
close(3)                                = 0
open("/usr/local/arm/3.3.2/lib/v5l/half/libc.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/v5l/libc.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/v5l",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/local/arm/3.3.2/lib/fast-mult/half/libc.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/fast-mult/half",
0xbeadd2d8) = -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/fast-mult/libc.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/fast-mult",
0xbeadd2d8) = -1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/half/libc.so.6",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/arm/3.3.2/lib/half", 0xbeadd2d8) =
-1 ENOENT (No such file or directory)
open("/usr/local/arm/3.3.2/lib/libc.so.6", O_RDONLY) =
3
read(3,
"\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h~\1\0004"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1194928,
...}) = 0
old_mmap(NULL, 1212024, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 3, 0) = 0x40099000
mprotect(0x401b3000, 56952, PROT_NONE)  = 0
old_mmap(0x401b9000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x118000) = 0x401b9000
old_mmap(0x401bf000, 7800, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =
0x401bf000
close(3)                                = 0
mprotect(0x40099000, 1155072, PROT_READ|PROT_WRITE) =
0
mprotect(0x40099000, 1155072, PROT_READ|PROT_EXEC) = 0
mprotect(0x4001f000, 466944, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001f000, 466944, PROT_READ|PROT_EXEC) = 0
ioctl(0, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0,
ws_ypixel=0}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost
isig icanon echo ...}) = 0
brk(0)                                  = 0x3b000
brk(0x3c000)                            = 0x3c000
brk(0)                                  = 0x3c000
lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) =
-1 ENOENT (No such file or directory)
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
= 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
brk(0)                                  = 0x3c000
brk(0x3d000)                            = 0x3d000
getdents64(3, /* 12 entries */, 4096)   = 288
lstat64("./etc", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./lib", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./sbin", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./dev", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./var", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./bin", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./proc", {st_mode=S_IFDIR|0555, st_size=0,
...}) = 0
lstat64("./usr", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
lstat64("./root", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
getdents64(3, /* 0 entries */, 4096)    = 0
close(3)                                = 0
open("/usr/local/arm/3.3.2/etc/localtime", O_RDONLY) =
-1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0644, st_rdev=makedev(4,
64), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost
isig icanon echo ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
socket(PF_FILE, SOCK_STREAM, 0)         = 3
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 819 detached

... There are cases wherein the program couldn't find
the lib files it's looking for (/etc/ld.so.preload,
/usr/local/arm/3.3.2/etc/ld.so.cache) but I couldn't
find these files in the toolchain either.

... The program is also looking for the other lib
files in the v5l/, v5l/fast_mult/ folders, but
eventually find them in the /lib folder, so I'm not
sure if this might be a problem..

... Any ideas?

Thanks,

Ed

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: init (busybox) problem on OSK5912

[Chetan Kapoor]

Re: init (busybox) problem on OSK5912

[chetan.kapoor]

Hi,

I have made some findings to resolve this issue. May be this is helpful for
you.

We were also facing the similar issue where the gdbserver when linked
dynamically was always resulting in a segmentation fault. We have ensured
that the version of libraries used while compilation are same in the target
also. But still , the gdbserver was resulting in a crash (always before
accept system call). 

After going through other mailing lists, I have found that this issue is
happening because of a bug in glibc libraries. I have rebuilt the glibc
libraries (2.3.5 version) for arm after deleting the sysdeps/arm/memset.S
file. I have used the newly built "libc.so.6" and "ld-linux.so.2" for
compilation and runtime environment. This time gdbserver and other
dynamically shared program worked fine.

May be you can give this step a try. I have followed the steps for building
toolchain from http://frank.harvard.edu/~coldwell/toolchain/

Regards,
Dinesh

++ Sent by Chetan Kapoor on behalf of Dinesh Arora ++

***********************  FSS-Unclassified   ***********************

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Re: init (busybox) problem on OSK5912

[Chetan Kapoor]

Hi,

I have made some findings to resolve this issue. May be this is helpful for you.

We were also facing the similar issue where the gdbserver when linked
dynamically was always resulting in a segmentation fault. We have
ensured that the version of libraries used while compilation are same
in the target also. But still , the gdbserver was resulting in a crash
(always before accept system call).

After going through other mailing lists, I have found that this issue
is happening because of a bug in glibc libraries. I have rebuilt the
glibc libraries (2.3.5 version) for arm after deleting the
sysdeps/arm/memset.S file. I have used the newly built "libc.so.6" and
"ld-linux.so.2" for compilation and runtime environment. This time
gdbserver and other dynamically shared program worked fine.

May be you can give this step a try. I have followed the steps for
building toolchain from http://frank.harvard.edu/~coldwell/toolchain/

Regards,
Dinesh

++ Sent by Chetan Kapoor on behalf of Dinesh Arora ++

***********************  FSS-Unclassified   ***********************