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

From: Greg Lonnon <[email-masked]>
Date: Thu, 28 Sep 2000 20:35:16 -0600

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:[email-masked]

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 29 Sep 2000 18:26:40 +0200

> start theard pc 400140 sp 7fffff90

Looks sane.

> 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.  

> 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.

> 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

---

From: Jun Sun <[email-masked]>
Date: Fri, 29 Sep 2000 16:05:46 -0700

> 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

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

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 30 Sep 2000 02:25:27 +0200

> recursive page faults.  See the page below.  Not sure if it is fixed in

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

  Ralf