Hung inside execve

Hung inside execve

[Francis Yu <francisy@luxn.com>]

Hello,
I have been going through the LinuxPPC archives, looking for answers to my
problem, but still could not proceed ahead. My problem is that the Linux
will hang after the line 'execve("bin/sh", argv_init, envp_init);' inside
the init function of the file main.c. I have added the printk statements
preceding each of the execve calls. The last prink should be right before
the panic statement but it did not get executed, therefore I suspect that
the culprit is 'execve("bin/sh", argv_init, envp_init);' .
My hardware is a custom 860T cpu with 16M RAM running at 50Mhz. I have
ported PPCboot 1.2.0 on the hardware. The linux I am trying to load is the
TMQ860L from DENX's development package. The Ramdisk image I am using is
also from DENX's ftp site. From that site there are two samples of Ramdisk,
one is "simple_ramdisk", the other is "ramdisk_2048". I have tried both and
got the same result. I am sure that I must have missed something, but I do
not know what I have overlooked. Could some body please help me out on this.
Thanks.
By the way, I can see a lot of people posting questions and receiving a lot
of answers or suggestions. But I seldom see the originator of the questions
follows up with the final solution of how the problem got fixed. In this
example, I do see that I am not the first one to ask this question, but I
just cannot find the solutions from the archives.

Francis

Captured from the screen:

Hit any key to stop autoboot:  0
=> setenv bootargs root=/dev/ram
=> imi 400000 600000

## Checking Image at 00400000 ...
   Image Name:   Linux-2.4.4 Debug
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    605902 Bytes = 591.7 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

## Checking Image at 00600000 ...
   Image Name:   2048K RAMdisk
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    506801 Bytes = 494.9 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
=> bootm 400000 600000
## Booting image at 00400000 ...
   Image Name:   Linux-2.4.4 Debug
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    605902 Bytes = 591.7 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x00F9BC18 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF0D
bd address  = 0x00F9BFC4
memstart    = 0x00000000
memsize     = 0x01000000
flashstart  = 0xFFE00000
flashsize   = 0x00200000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xFA000000
bootflags   = 0x00000001
intfreq     =     50 MHz
busfreq     =     50 MHz
ethaddr     = 00:10:EC:00:1D:0B
IP addr     = 192.168.1.65
baudrate    =   9600 bps
## Loading RAMDisk Image at 00600000 ...
   Image Name:   2048K RAMdisk
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    506801 Bytes = 494.9 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## initrd at 0x00600040 ... 0x0067BBF0 (len=506801=0x7BBB1)
   Loading Ramdisk to 00f1f000, end 00f9abb1 ... OK
## Transferring control to Linux (at address 00000000) ...
Linux version 2.4.4 (root@localhost.localdomain) (gcc version 2.95.3
20010315 (r
elease/MontaVista)) #15 Tue Nov 26 10:13:20 PST 2002
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram
Decrementer Frequency: 3125000
Calibrating delay loop... 49.76 BogoMIPS
Memory: 13848k available (1168k kernel code, 508k data, 52k init, 0k
highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
CPM UART driver version 0.03
ttyS0 on SMC1 at 0x0280, BRG1
ttyS1 on SMC2 at 0x0380, BRG2
pty: 256 Unix98 ptys configured
block: queued sectors max/low 9120kB/3040kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
PCMCIA slot @: phys mem ffffffff...00000000 (size 00000001)
PCMCIA slot has not been defined! Using A as default
No card in slot A: PIPR=ff00ff00
eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:1d:0b
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 494k freed
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
AB.
CFI: Found no TQM8xxL Bank 0 device at location zero
CFI: Found no TQM8xxL Bank 1 device at location zero
CFI: Found no TQM8xxL Bank 2 device at location zero
CFI: Found no TQM8xxL Bank 3 device at location zero
TQM8xxL: No support flash chips found!
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
IP-Config: Incomplete network configuration information.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory:  52k init
 Executing command:<NULL>			; printk statements added by
me.
 /sbini/init
 /etc/init
 /bin/init
 /bin/sh


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Hung inside execve

[Wolfgang Denk]

In message <B0CD235912AED411B69800D0B7C9F60F1DF88A@mail> you wrote:
>
> I have been going through the LinuxPPC archives, looking for answers to my
> problem, but still could not proceed ahead. My problem is that the Linux
> will hang after the line 'execve("bin/sh", argv_init, envp_init);' inside
> the init function of the file main.c. I have added the printk statements
> preceding each of the execve calls. The last prink should be right before
> the panic statement but it did not get executed, therefore I suspect that
> the culprit is 'execve("bin/sh", argv_init, envp_init);' .

Ummm... in situations like this life is _much_ easier  when  you  can
use a debugger. Get yourself a BDI2000!

> My hardware is a custom 860T cpu with 16M RAM running at 50Mhz. I have
> ported PPCboot 1.2.0 on the hardware. The linux I am trying to load is the
> TMQ860L from DENX's development package. The Ramdisk image I am using is
> also from DENX's ftp site. From that site there are two samples of Ramdisk,
> one is "simple_ramdisk", the other is "ramdisk_2048". I have tried both and
> got the same result. I am sure that I must have missed something, but I do
> not know what I have overlooked. Could some body please help me out on this.

A ramdisk environment is noce for a target  system,  but  a  hell  to
debug.  Configure  your  system to mount the root filesystem over NFS
instead. Then run a network sniffer (like "ethereal") and you can see
pretty well which binaries and libraries are being loaded, and  which
other files are accessed.

This is much, much more efficient that  using  a  ramdisk  where  you
cannot  see  anything. Especially if you don't use a BDI2000, but I'm
repeating myself.

> By the way, I can see a lot of people posting questions and receiving a lot
> of answers or suggestions. But I seldom see the originator of the questions
> follows up with the final solution of how the problem got fixed. In this

Ah, someone who remembers good old usenet netiquette!

...
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> PCMCIA slot @: phys mem ffffffff...00000000 (size 00000001)
> PCMCIA slot has not been defined! Using A as default
> No card in slot A: PIPR=ff00ff00

Be careful when your system is NOT a TQM860L module! The PCMCIA  code
does  some  pretty hardware specific things like enabling / disabling
bus drivers and switching the power to the PCMCIA slot - at least  it
does  so  on  the TQM8xxL. I habe no idea what might be connected to
those pins on your board...

...
> JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
> JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
> AB.
> CFI: Found no TQM8xxL Bank 0 device at location zero
> CFI: Found no TQM8xxL Bank 1 device at location zero
> CFI: Found no TQM8xxL Bank 2 device at location zero
> CFI: Found no TQM8xxL Bank 3 device at location zero
> TQM8xxL: No support flash chips found!

You should probably disable features that don;t exist on your  board,
or that are not compatible.

>  /sbini/init
^^^^^^^^^^^^^^   Really??? Is this really /sbini ?
>  /etc/init
>  /bin/init
>  /bin/sh

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
        "That we but teach bloody instructions,
        which, being taught, return to plague the inventor..."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Hung inside execve

[Jerry Van Baren]

At 09:40 PM 11/26/2002 +0100, Wolfgang Denk wrote:

>In message <B0CD235912AED411B69800D0B7C9F60F1DF88A@mail> you wrote:
> >
> > I have been going through the LinuxPPC archives, looking for answers to my
> > problem, but still could not proceed ahead. My problem is that the Linux
> > will hang after the line 'execve("bin/sh", argv_init, envp_init);' inside
> > the init function of the file main.c. I have added the printk statements
> > preceding each of the execve calls. The last prink should be right before
> > the panic statement but it did not get executed, therefore I suspect that
> > the culprit is 'execve("bin/sh", argv_init, envp_init);' .

For what it is worth, my first thought when I saw this is that you probably
have a shared library missing on your RAM disk.  As suggested by Wolfgang,
use NFS and see where your system stops requesting files and what file it
(probably) was unable to find.  You can use binutils & company to figure
out what symbols/libraries are needed by /bin/sh, but it is generally
easier to just run it using NFS and sniff the ether.

>Ummm... in situations like this life is _much_ easier  when  you  can
>use a debugger. Get yourself a BDI2000!

BDI-2000: better than chicken soup for whatever ails you ;-)

gvb

[lots more good advice snipped]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Hung inside execve

[Rod Boyce]

BDI2000 - Better than sliced bread and floating soap....

 -----Original Message-----
From: 	Jerry Van Baren [mailto:vanbaren_gerald@si.com]
Sent:	Tuesday, November 26, 2002 1:04 PM
To:	linuxppc-embedded@lists.linuxppc.org
Subject:	Re: Hung inside execve



BDI-2000: better than chicken soup for whatever ails you ;-)

gvb

[lots more good advice snipped]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Hung inside execve

[Wolfgang Denk]

Dear Francis,

in message <B0CD235912AED411B69800D0B7C9F60F1DF8A7@mail> you wrote:
>
> Thanks a lot for your reply and hints. I finally got the OK to purchase a
> BDI2000. While I am waiting for its arrival, I want to spend more time
> looking into my problem of hanging right after the line "execve /bin/sh". My
> question is: Is it normal to get the return value 0xfffffffe from the
> functions "execve /sbin/init", "execve /etc/init", and 'execve /bin/init",
> while the line "execve /bin/sh" returns zero? I am using the

Check your root filesystem.

Which of the files "/bin/sh", "/sbin/init", "/etc/init" and "/bin/init"
do exist, and which don't?

> mini-2048kB-ramdiskimage.gz downloaded from DENX.

In this filesystem only "/bin/sh" exists, while the ohers don't. This
explains the exit codes.

> Should I spend the time in studying how to build my own ramdisk? Thanks.

I have put a set of more complete ramdisk images (based on  the  SELF
RPM  from our ELDK 2.0 distribution) for download from or FTP server;
see ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/

But there is nothing wrong with the mini-2048kB-ramdiskimage.gz  file
- it still works fine here.

I think you should try to boot the system with root  filesystem  over
NFS  instead - it is much easier to debug (use a network sniffer like
ethereal to check the traffic on the wire).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Business is like a wheelbarrow. Nothing ever happens until you  start
pushing.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/