* init (busybox) problem on OSK5912 [not found] <20060503194919.7EDC38062D@linux.omap.com> @ 2006-05-04 6:47 ` Eduardo Gallofin 2006-05-04 16:43 ` andrzej zaborowski 0 siblings, 1 reply; 9+ messages in thread From: Eduardo Gallofin @ 2006-05-04 6:47 UTC (permalink / raw) To: linux-omap-open-source 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: init (busybox) problem on OSK5912 2006-05-04 6:47 ` init (busybox) problem on OSK5912 Eduardo Gallofin @ 2006-05-04 16:43 ` andrzej zaborowski 2006-05-05 0:10 ` Eduardo Gallofin 2006-05-05 2:39 ` Eduardo Gallofin 0 siblings, 2 replies; 9+ messages in thread From: andrzej zaborowski @ 2006-05-04 16:43 UTC (permalink / raw) To: Eduardo Gallofin; +Cc: linux-omap-open-source [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* init (busybox) problem on OSK5912 2006-05-04 16:43 ` andrzej zaborowski @ 2006-05-05 0:10 ` Eduardo Gallofin 2006-05-05 2:39 ` Eduardo Gallofin 1 sibling, 0 replies; 9+ messages in thread From: Eduardo Gallofin @ 2006-05-05 0:10 UTC (permalink / raw) To: balrogg; +Cc: linux-omap-open-source 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: init (busybox) problem on OSK5912 2006-05-04 16:43 ` andrzej zaborowski 2006-05-05 0:10 ` Eduardo Gallofin @ 2006-05-05 2:39 ` Eduardo Gallofin 1 sibling, 0 replies; 9+ messages in thread From: Eduardo Gallofin @ 2006-05-05 2:39 UTC (permalink / raw) To: balrogg; +Cc: linux-omap-open-source 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: init (busybox) problem on OSK5912 @ 2006-05-10 7:38 Chetan Kapoor 0 siblings, 0 replies; 9+ messages in thread From: Chetan Kapoor @ 2006-05-10 7:38 UTC (permalink / raw) To: linux-omap-open-source 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 *********************** ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: init (busybox) problem on OSK5912 @ 2006-05-10 7:21 chetan.kapoor 0 siblings, 0 replies; 9+ messages in thread From: chetan.kapoor @ 2006-05-10 7:21 UTC (permalink / raw) To: linux-omap-open-source 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/ . ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: init (busybox) problem on OSK5912 @ 2006-05-10 7:08 Chetan Kapoor 0 siblings, 0 replies; 9+ messages in thread From: Chetan Kapoor @ 2006-05-10 7:08 UTC (permalink / raw) To: linux-omap-open-source; +Cc: egallofin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Fw: init (busybox) problem on OSK5912 @ 2006-05-04 7:19 Chetan Kapoor 2006-05-04 7:59 ` Eduardo Gallofin 0 siblings, 1 reply; 9+ messages in thread From: Chetan Kapoor @ 2006-05-04 7:19 UTC (permalink / raw) To: Eduardo Gallofin; +Cc: linux-omap-open-source Ed Could you tell me where is the option of compiling busybox with or without shared libs. I have Busybox 1.0.0 running on OMAP 730 P2, it was fine till we used the included apps (ls, pwd etc), but we then tried running gdbserver on the target, which gives a segmentation fault while running, seems as if my problem is also related to shared libs. Also, I had to manually copy libc-2.3.2.so & libthread_db-1.0.so to make gdbserver start on the target, before which we were not even able to launch gdbserver on the target. If I complie Busybox with shared libs, will I see a 'lib' folder at path /lib or /usr/local/lib on the target's rootfs? Your reply will be of great help. Cheers!! Chetan Eduardo Gallofin <egallofin@yahoo.com> Sent by: linux-omap-open-source-bounces@linux.omap.com 05/04/2006 12:17 PM To linux-omap-open-source@linux.omap.com cc Subject init (busybox) problem on OSK5912 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 _______________________________________________ Linux-omap-open-source mailing list Linux-omap-open-source@linux.omap.com http://linux.omap.com/mailman/listinfo/linux-omap-open-source *********************** FSS-Unclassified *********************** *********************** FSS-Unclassified *********************** ^ permalink raw reply [flat|nested] 9+ messages in thread
* init (busybox) problem on OSK5912 2006-05-04 7:19 Fw: " Chetan Kapoor @ 2006-05-04 7:59 ` Eduardo Gallofin 0 siblings, 0 replies; 9+ messages in thread From: Eduardo Gallofin @ 2006-05-04 7:59 UTC (permalink / raw) To: Chetan Kapoor; +Cc: linux-omap-open-source 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20060501170002.24B3A8062B@linux.omap.com>]
* init (busybox) problem on OSK5912 [not found] <20060501170002.24B3A8062B@linux.omap.com> @ 2006-05-02 7:09 ` Eduardo Gallofin 0 siblings, 0 replies; 9+ messages in thread From: Eduardo Gallofin @ 2006-05-02 7:09 UTC (permalink / raw) To: linux-omap-open-source 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-05-10 7:38 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060503194919.7EDC38062D@linux.omap.com>
2006-05-04 6:47 ` init (busybox) problem on OSK5912 Eduardo Gallofin
2006-05-04 16:43 ` andrzej zaborowski
2006-05-05 0:10 ` Eduardo Gallofin
2006-05-05 2:39 ` Eduardo Gallofin
2006-05-10 7:38 Chetan Kapoor
-- strict thread matches above, loose matches on Subject: below --
2006-05-10 7:21 chetan.kapoor
2006-05-10 7:08 Chetan Kapoor
2006-05-04 7:19 Fw: " Chetan Kapoor
2006-05-04 7:59 ` Eduardo Gallofin
[not found] <20060501170002.24B3A8062B@linux.omap.com>
2006-05-02 7:09 ` Eduardo Gallofin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox