execve system call question

execve system call question

[Sangmoon Kim]

Hi!
I'm debugging a custom MPC755 board
with linuxppc_devel from montavista rsync,
and /opt/hardhat/devkit/ppc/7xx/target for NFS root.
It booted and stoped after the message.

--------------------------------------------------------
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
IP-Config: Complete:
      device=eth0, addr=203.239.17.200, mask=255.255.255.0, gw=203.239.17.57,
     host=dogoil, domain=, nis-domain=(none),
     bootserver=203.239.17.57, rootserver=203.239.17.57, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 203.239.17.57
Looking up port of RPC 100005/1 on 203.239.17.57
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 76k init
--------------------------------------------------------

I traced the code and the point of stopping is after calling
execve("/sbin/init", argv_init, envp_init)
in init/main.c

I was trying to trace more, but it was impossible
because of the complexity of the code.

Is there any method to debug this?
I'm debugging it for a month.

Please help me.

- Sangmoon Kim -

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

Re: execve system call question

[None Atall]

 Well, after that command, the filesystem takes
place. You can't put anything in the kernel. The
procedure for calling and executing init works fine.
Is the root filesystem correct? Have you tried to
upload a ramdisk image in ram? If you are sure that
all these are correct, then do you have a JTAG
Debugger? (OCD Commander ...)

                     D. Meidanis

--- Sangmoon Kim <dogoil@etinsys.com> wrote:
>
> Hi!
> I'm debugging a custom MPC755 board
> with linuxppc_devel from montavista rsync,
> and /opt/hardhat/devkit/ppc/7xx/target for NFS root.
> It booted and stoped after the message.
>
>
--------------------------------------------------------
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 1024 buckets,
> 8Kbytes
> TCP: Hash tables configured (established 8192 bind
> 8192)
> IP-Config: Complete:
>       device=eth0, addr=203.239.17.200,
> mask=255.255.255.0, gw=203.239.17.57,
>      host=dogoil, domain=, nis-domain=(none),
>      bootserver=203.239.17.57,
> rootserver=203.239.17.57, rootpath=
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Looking up port of RPC 100003/2 on 203.239.17.57
> Looking up port of RPC 100005/1 on 203.239.17.57
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 76k init
>
--------------------------------------------------------
>
> I traced the code and the point of stopping is after
> calling
> execve("/sbin/init", argv_init, envp_init)
> in init/main.c
>
> I was trying to trace more, but it was impossible
> because of the complexity of the code.
>
> Is there any method to debug this?
> I'm debugging it for a month.
>
> Please help me.
>
> - Sangmoon Kim -
>
>


=====
-------------------------------------------------
  Dhmhtrios Meidanis
-Degree in Mathematics, University of the Aegean.
-Master in Computer Architecture and Digital
 Systems, University of Crete.
  Greece.
-------------------------------------------------


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

Re: execve system call question

[Wolfgang Denk]

In message <008901c1beb1$409cc7f0$1a11efcb@industrialDiv.hanasys.co.kr> you wrote:
>
> I traced the code and the point of stopping is after calling
> execve("/sbin/init", argv_init, envp_init)
> in init/main.c
>
> I was trying to trace more, but it was impossible
> because of the complexity of the code.

It's not impossible. In fact, it's quite simple.

You're running with root filesystem over NFS,  so  just  start  up  a
network  sniffer  (like  ethereal)  and  check  all  NFS requests and
replys. Probably  something  is  missing  in  your  root  filesystem.
Something essential, like /dev/console or so.

> Is there any method to debug this?

Yes, attach a BDI2000 and check where you are...

> I'm debugging it for a month.

Urghhh...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Use C++ to confuse your enemies; use C to produce stable code.

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

Re: execve system call question

[Christian Pellegrin]

On Tue, 26 Feb 2002, Sangmoon Kim wrote:

>
> and /opt/hardhat/devkit/ppc/7xx/target for NFS root.

> VFS: Mounted root (nfs filesystem).
>
> Is there any method to debug this?
> I'm debugging it for a month.
>

I'll suggest:

1) turn on debugging on the nfs server

2) generate a trivial hello world program and put it instead of
/sbin/init. So to be sure it's a ppc executable. Start with a static
linked one,it's a bit difficult to do dynamic linking right at the first
time ;-)

Bye!


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

RE: execve system call question

[Derrik Weeks]

Hi,

This sounds like a problem I had a while back with the location of the IMMR
of on my processor.  What I discovered (via the archives of this mail list)
is the IMMR needs to be located in high memory above F0000000.  Check your
code to see if the memory map for your custom board has placed the IMMR at a
low memory address.

>From experience I know that if this is your issue, your kernel will crash
whether you're running NFS or a ram disk.  Once you move the IMMR to high
memory, you'll get to shell prompt with no problem.  I'm 75% sure you're
looking at the same situation as I was, but if not, I wish you luck in your
troubleshooting.

>From what I can tell by my limited time on this mail list, this issue has
snagged many people new to Linux.  It's apparently well known in lore that
the IMMR needs to be in high memory, it's just not particularly well
documented, although those details can be found with enough digging.

Hope this helps!
Derrik Weeks
Digital Hardware Architect
IOtech, Inc.

-----Original Message-----
From: Sangmoon Kim [mailto:dogoil@etinsys.com]
Sent: Tuesday, February 26, 2002 5:35 AM
To: linuxppc-embedded
Subject: execve system call question



Hi!
I'm debugging a custom MPC755 board
with linuxppc_devel from montavista rsync,
and /opt/hardhat/devkit/ppc/7xx/target for NFS root.
It booted and stoped after the message.

--------------------------------------------------------
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
IP-Config: Complete:
      device=eth0, addr=203.239.17.200, mask=255.255.255.0,
gw=203.239.17.57,
     host=dogoil, domain=, nis-domain=(none),
     bootserver=203.239.17.57, rootserver=203.239.17.57, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 203.239.17.57
Looking up port of RPC 100005/1 on 203.239.17.57
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 76k init
--------------------------------------------------------

I traced the code and the point of stopping is after calling
execve("/sbin/init", argv_init, envp_init)
in init/main.c

I was trying to trace more, but it was impossible
because of the complexity of the code.

Is there any method to debug this?
I'm debugging it for a month.

Please help me.

- Sangmoon Kim -


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

Re: execve system call question

[Sangmoon Kim]

Hi None Atall!

I think the root file system is correct because it's from Hard Hat Linux.
I tried some ramdisk images but the result was the same.
And I don't have JTAG debugger.

Thank you for the replay.

----- Original Message -----
From: "None Atall" <linux_meis@yahoo.com>
To: "Sangmoon Kim" <dogoil@etinsys.com>; "linuxppc-embedded" <linuxppc-embedded@lists.linuxppc.org>
Sent: Tuesday, February 26, 2002 10:11 PM
Subject: Re: execve system call question


> Well, after that command, the filesystem takes
> place. You can't put anything in the kernel. The
> procedure for calling and executing init works fine.
> Is the root filesystem correct? Have you tried to
> upload a ramdisk image in ram? If you are sure that
> all these are correct, then do you have a JTAG
> Debugger? (OCD Commander ...)
>
>                      D. Meidanis
>
> --- Sangmoon Kim <dogoil@etinsys.com> wrote:
> >
> > Hi!
> > I'm debugging a custom MPC755 board
> > with linuxppc_devel from montavista rsync,
> > and /opt/hardhat/devkit/ppc/7xx/target for NFS root.
> > It booted and stoped after the message.
> >
> >
> --------------------------------------------------------
> > NET4: Linux TCP/IP 1.0 for NET4.0
> > IP Protocols: ICMP, UDP, TCP
> > IP: routing cache hash table of 1024 buckets,
> > 8Kbytes
> > TCP: Hash tables configured (established 8192 bind
> > 8192)
> > IP-Config: Complete:
> >       device=eth0, addr=203.239.17.200,
> > mask=255.255.255.0, gw=203.239.17.57,
> >      host=dogoil, domain=, nis-domain=(none),
> >      bootserver=203.239.17.57,
> > rootserver=203.239.17.57, rootpath=
> > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> > Looking up port of RPC 100003/2 on 203.239.17.57
> > Looking up port of RPC 100005/1 on 203.239.17.57
> > VFS: Mounted root (nfs filesystem).
> > Freeing unused kernel memory: 76k init
> >
> --------------------------------------------------------
> >
> > I traced the code and the point of stopping is after
> > calling
> > execve("/sbin/init", argv_init, envp_init)
> > in init/main.c
> >
> > I was trying to trace more, but it was impossible
> > because of the complexity of the code.
> >
> > Is there any method to debug this?
> > I'm debugging it for a month.
> >
> > Please help me.
> >
> > - Sangmoon Kim -
> >
> >
>
>
> =====
> -------------------------------------------------
>   Dhmhtrios Meidanis
> -Degree in Mathematics, University of the Aegean.
> -Master in Computer Architecture and Digital
>  Systems, University of Crete.
>   Greece.
> -------------------------------------------------
>
>

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

Re: execve system call question

[Sangmoon Kim]

Hi Cristian Pellegrin!

I tried the 'hello world' thing.
but it didn't worked.

Thank you for the reply.

----- Original Message -----
From: "Christian Pellegrin" <chri@infis.univ.trieste.it>
To: "Sangmoon Kim" <dogoil@etinsys.com>
Cc: "linuxppc-embedded" <linuxppc-embedded@lists.linuxppc.org>
Sent: Tuesday, February 26, 2002 10:27 PM
Subject: Re: execve system call question


> On Tue, 26 Feb 2002, Sangmoon Kim wrote:
>
> >
> > and /opt/hardhat/devkit/ppc/7xx/target for NFS root.
>
> > VFS: Mounted root (nfs filesystem).
> >
> > Is there any method to debug this?
> > I'm debugging it for a month.
> >
>
> I'll suggest:
>
> 1) turn on debugging on the nfs server
>
> 2) generate a trivial hello world program and put it instead of
> /sbin/init. So to be sure it's a ppc executable. Start with a static
> linked one,it's a bit difficult to do dynamic linking right at the first
> time ;-)
>
> Bye!
>
>

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

Re: execve system call question

[Sangmoon Kim]

Hi Derrik Weeks!

> IMMR needs to be located in high memory above F0000000.

The MPC755 doesn't have an IMMR.
If it is because all the I/O should be locaced above F0000000, please let me know. The serial port of my board is located at 0x78000000.

> kernel will crash whether you're running NFS or a ram disk.

You are right I tried ramdisk but kernel crashed.

Thank you for the reply.

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

Re: execve system call question

[Sangmoon Kim]

Hi Wolfgang Denk.

> You're running with root filesystem over NFS,  so  just  start  up  a
> network  sniffer  (like  ethereal)  and  check  all  NFS requests and
> replys. Probably  something  is  missing  in  your  root  filesystem.
> Something essential, like /dev/console or so.

The root file system is from Hardhat Linux. I think it's correct because so many people use it without complain. and the /dev/console exist.
I tried ramdisk. But the result was same.

Thank you for the reply.

----- Original Message -----
From: "Wolfgang Denk" <wd@denx.de>
To: "Sangmoon Kim" <dogoil@etinsys.com>
Cc: "linuxppc-embedded" <linuxppc-embedded@lists.linuxppc.org>
Sent: Tuesday, February 26, 2002 10:21 PM
Subject: Re: execve system call question


>
> In message <008901c1beb1$409cc7f0$1a11efcb@industrialDiv.hanasys.co.kr> you wrote:
> >
> > I traced the code and the point of stopping is after calling
> > execve("/sbin/init", argv_init, envp_init)
> > in init/main.c
> >
> > I was trying to trace more, but it was impossible
> > because of the complexity of the code.
>
> It's not impossible. In fact, it's quite simple.
>
> You're running with root filesystem over NFS,  so  just  start  up  a
> network  sniffer  (like  ethereal)  and  check  all  NFS requests and
> replys. Probably  something  is  missing  in  your  root  filesystem.
> Something essential, like /dev/console or so.
>
> > Is there any method to debug this?
>
> Yes, attach a BDI2000 and check where you are...
>
> > I'm debugging it for a month.
>
> Urghhh...
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> Use C++ to confuse your enemies; use C to produce stable code.
>
>
>

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

Re: execve system call question

[Sangmoon Kim]

RE: execve system call questionHi Subhachandra Chandra.

> It could be that your ld.so* does not have execute >permissions. The 2.4.2 and 2.4.4 kernels did not care >about this but the 2.4.17 cares about it. I do not know >when the actual switchover happened.  Since you are >doing NFS there may be other files which have incorrect >permissions.

ld.so* has execute permission.
I will try 2.4.2 then.

Thank you.


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

Re: execve system call question

[Sangmoon Kim]

Hi Claus Gindhart

> I assume, that Your code is stuck inside the init process.
> There is an easy to way to find out, if my assumption is right.
> - Use a sash (Statically linked standalone shell) and replace /sbin/init
> with the executable.
> - If You get a prompt now, the execve works o.k, the hangup is inside init
>
> The further proceeding depends on the result of the above test.
>

I tried other thing like /bin/bash and 'hello world' things. but it didnot worked.

Thank you!

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

Re: execve system call question

[Sangmoon Kim]

Hi Kerl, John

> I found on this mailing list that the IMMR must be located
> *above* 0xc0000000.  For example, 0xf0000000.

The MPC755 doesn't have IMMR.
If it means all the I/O should be located above 0xf0000000 please let me know.
My board has a serial port at 0x78000000.

Thank you!

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

Re: execve system call question

[Wolfgang Denk]

In message <005e01c1bf2d$101798e0$1a11efcb@industrialDiv.hanasys.co.kr> you wrote:
>
> I think the root file system is correct because it's from Hard Hat Linux.

Not necessarily so. You may have made some  mistakes  when  selecting
and installing the packages.

> I tried some ramdisk images but the result was the same.
> And I don't have JTAG debugger.

Get yourself a BDI2000 then.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

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

RE: execve system call question

[Derrik Weeks]

Greetings Sangmoon,

My apologies, I thought that most PPC based chips had configuration or
status registers that were not in the SPR space (i.e. IMMR based regs).  A
little research says this is not the case.  As I understand it (with thanks
to Wolfgang) Linux reserves memory space below 80000000 for user
applications.  In my case I had my IMMR based registers mapped below this
value, and the kernel was setting mapping for this space to virtual =
physical, which caused my problem.  You may have the same issue with your
serial port, it would be worth a try to move it to high memory and see if
this resolves your problem.

Best of luck,
Derrik Weeks

-----Original Message-----
From: Sangmoon Kim [mailto:dogoil@etinsys.com]
Sent: Tuesday, February 26, 2002 8:31 PM
To: Derrik Weeks; linuxppc-embedded
Subject: Re: execve system call question


Hi Derrik Weeks!

> IMMR needs to be located in high memory above F0000000.

The MPC755 doesn't have an IMMR.
If it is because all the I/O should be locaced above F0000000, please let me
know. The serial port of my board is located at 0x78000000.

> kernel will crash whether you're running NFS or a ram disk.

You are right I tried ramdisk but kernel crashed.

Thank you for the reply.

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

Re: execve system call question

[Sangmoon Kim]

Hi Derrik Weeks,

I got the bash prompt.

> A little research says this is not the case.  As I understand it (with thanks
> to Wolfgang) Linux reserves memory space below 80000000 for user
> applications.  In my case I had my IMMR based registers mapped below this
> value, and the kernel was setting mapping for this space to virtual =
> physical, which caused my problem.  You may have the same issue with your
> serial port, it would be worth a try to move it to high memory and see if
> this resolves your problem.

I changed the hardware by some jump wire, so the serial port is now located at 0xff000000.
I'll try the virtual != physical thing with my original hardware.

Thank you for the reply!
- Sangmoon Kim -

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

Re: execve system call question

[Sangmoon Kim]

Hi Kerl, John,

I got the bash prompt

I changed the hardware with some jump wire so that the serial port is located at 0xff000000.

Thank you!
- Sangmoon Kim -

----- Original Message -----
From: "Kerl, John" <John.Kerl@Avnet.com>
To: "'Sangmoon Kim'" <dogoil@etinsys.com>
Sent: Thursday, February 28, 2002 1:51 AM
Subject: RE: execve system call question


> I do not know for certain that all I/O must be above 0xc0000000.
> However, I do know once I moved all my I/O above 0xc0000000,
> my board no longer hung while starting init.
>
> Note that 0xc0000000 and up is used for kernel RAM.  So, don't
> put a device at 0xc0000000.  And you may have flash around
> 0xfff00000; if so, that is another place to avoid.
>
> I would strongly suggest moving your serial port to, say, 0xf0000000.
> I do know that your symptoms resemble the symptoms that I saw,
> and that at least two other people saw.
>
> Can you try it out?
>
> -----Original Message-----
> From: Sangmoon Kim [mailto:dogoil@etinsys.com]
> Sent: Tuesday, February 26, 2002 6:48 PM
> To: linuxppc-embedded@lists.linuxppc.org; Kerl, John
> Subject: Re: execve system call question
>
>
>
> Hi Kerl, John
>
> > I found on this mailing list that the IMMR must be located
> > *above* 0xc0000000.  For example, 0xf0000000.
>
> The MPC755 doesn't have IMMR.
> If it means all the I/O should be located above 0xf0000000 please let me
> know.
> My board has a serial port at 0x78000000.
>
> Thank you!
>
>

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