problems execve("/sbin/init",...)

problems execve("/sbin/init",...)

[Greg Lonnon]

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

Hi,

I am trying to port linux-2.2.14/MIPS to a new board containing a QED
R5271 MIPS processor.  I am having problems with execve("/sbin/init,...)
in init/main.c.  The "/sbin/init" is not being called by the kernel.  I
am nfs root mounting the "simple" filesystem during the kernel boot, and
the network and nfs mount seem to be working (I have read and printk'ed
/etc/rc at the end of main.c::init()).

Things I have tried to debug with:
1) Have written a small tcp/ip server to accept a socket connection,
have execve this instead of "/sbin/init".  The server will not accept
connections.  Thus, I believe it's not running.
2) Have statically linked the server and have instrumented binfmt_elf.c
and fs/exec.c with debug.  The loader seems be working correctly, and
arch/mips/kernel/process.c::start_thread(...) is called with the
corrected pc and sp. The pc is the entry point in the elf file and the
sp is 0x7ffff90.

Some printk debug from binfmt_elf.c:
(start_brk) 10004e04
(end_code) 4782a0
(start_code) 400000
(end_data) 10003dbc
(start_stack) 7fffff90
(brk) 10004e04
start theard pc 400140 sp 7fffff90

3) Have been trying to get printk support into system calls by rewriting
read_write.c::sys_write (and friends) to do a printk() at the start of
the call.  I have written a statically linked program that calls
write(0,"here",4).  This didn't result in printk output.  I would
suspect that the program is not being correctly execve.

So, my questions are:
1) Does anyone have a good way to debug in this small window going
between kernel mode and user mode for the first time?
2) Is there anything else I could try to prove out that the kernel is
going into user mode?
3) Has anyone else had these issues?

My command_line is: 
console=ttyS0,115200 root=/dev/nfs
nfsroot=192.168.1.12:/projects/mips/fs ip=192.168.1.211:192.168.1.1:::::

Also, My /dev/console is pointing to /dev/ttyS0 and it seems to be dead,
I can't printf() to stdout.

Thanks,
Greg
-- 
Greg Lonnon                     mailto:glonnon@ridgerun.com

[-- Attachment #2: Card for Greg Lonnon --]
[-- Type: text/x-vcard, Size: 359 bytes --]

begin:vcard 
n:Lonnon;Greg
tel;fax:208-331-2227
tel;home:208-323-1724
tel;work:208-331-2226 ext 18
x-mozilla-html:FALSE
url:www.ridgerun.com
org:RidgeRun, Inc
version:2.1
email;internet:glonnon@ridgerun.com
title:Senior Kernel Developer
adr;quoted-printable:;;200 N. 4th Street	=0D=0ASuite 101;Boise;ID;83702;USA
x-mozilla-cpt:;-7104
fn:Greg Lonnon
end:vcard

Re: problems execve("/sbin/init",...)

[Ralf Baechle]

On Thu, Sep 28, 2000 at 08:35:16PM -0600, Greg Lonnon wrote:

> Some printk debug from binfmt_elf.c:
> (start_brk) 10004e04
> (end_code) 4782a0
> (start_code) 400000
> (end_data) 10003dbc
> (start_stack) 7fffff90
> (brk) 10004e04
> start theard pc 400140 sp 7fffff90

Looks sane.

> 3) Have been trying to get printk support into system calls by rewriting
> read_write.c::sys_write (and friends) to do a printk() at the start of
> the call.  I have written a statically linked program that calls
> write(0,"here",4).  This didn't result in printk output.  I would
> suspect that the program is not being correctly execve.

I suggest you check that your program actually gets paged into memory by
enabling the debug printf near the start of do_page_fault() in
arch/mips/mm/fault.c.

One thing which may happend and will freeze the process in question is
if you take recursive page faults, that is the page fault handler will
re-enter itself and down() in do_page_fault() will be called a second
time for the same process before a match up() call for the previous
invocation.  

> So, my questions are:
> 1) Does anyone have a good way to debug in this small window going
> between kernel mode and user mode for the first time?
> 2) Is there anything else I could try to prove out that the kernel is
> going into user mode?
> 3) Has anyone else had these issues?

I don't have any reports like this.

Many of the obscure bug reports like this are caused by the usage of
inapropriate tools to build the kernel.  The recommended versions are
egcs 1.0.3a and binutils 2.8.1 with the latest patches from oss.sgi.com
applied. To make live easier for you there are also source and binary
rpms available there somewhere under /pub/linux/mips.

> My command_line is: 
> console=ttyS0,115200 root=/dev/nfs
> nfsroot=192.168.1.12:/projects/mips/fs ip=192.168.1.211:192.168.1.1:::::
> 
> Also, My /dev/console is pointing to /dev/ttyS0 and it seems to be dead,
> I can't printf() to stdout.

/dev/console should a character device with major 5 and minor 1.  Everything
else is either outdated, hackish or even broken.

  Ralf

Re: problems execve("/sbin/init",...)

[Jun Sun]

Greg Lonnon wrote:
> 
> So, my questions are:
> 1) Does anyone have a good way to debug in this small window going
> between kernel mode and user mode for the first time?

Not really.  One time I had similar problem.  I was able to figure out
the problem by setting breakpoints in fault handlers.

> 2) Is there anything else I could try to prove out that the kernel is
> going into user mode?

Try to set breakpoint in fault handlers.

> 3) Has anyone else had these issues?
>

I found one bug in arch/mm/r4xx0.c, where cache invalidation causes
recursive page faults.  See the page below.  Not sure if it is fixed in
the tree yet.

diff -Nru linux/arch/mips/mm/r4xx0.c.orig linux/arch/mips/mm/r4xx0.c
--- linux/arch/mips/mm/r4xx0.c.orig     Sun Jul 30 20:39:50 2000
+++ linux/arch/mips/mm/r4xx0.c  Thu Aug 10 16:08:20 2000
@@ -1972,7 +1972,8 @@
        if (!(vma->vm_flags & VM_EXEC))
                return;

-       blast_icache32_page(address);
+        address = KSEG0 + (address & PAGE_MASK & (dcache_size - 1));
+        blast_icache32_page_indexed(address);
 }

 /*
 
Jun

Re: problems execve("/sbin/init",...)

[Ralf Baechle]

On Fri, Sep 29, 2000 at 04:05:46PM -0700, Jun Sun wrote:

> I found one bug in arch/mm/r4xx0.c, where cache invalidation causes
> recursive page faults.  See the page below.  Not sure if it is fixed in
> the tree yet.

This bug doesn't affect 2.2 which is the kernel in question.

  Ralf