Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: Greg Lonnon <glonnon@ridgerun.com>
Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr
Subject: Re: problems execve("/sbin/init",...)
Date: Fri, 29 Sep 2000 18:26:40 +0200	[thread overview]
Message-ID: <20000929182640.F16050@bacchus.dhis.org> (raw)
In-Reply-To: <39D3FFE4.35E83599@ridgerun.com>; from glonnon@ridgerun.com on Thu, Sep 28, 2000 at 08:35:16PM -0600

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

  reply	other threads:[~2000-09-29 22:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-29  2:35 problems execve("/sbin/init",...) Greg Lonnon
2000-09-29 16:26 ` Ralf Baechle [this message]
2000-09-29 23:05 ` Jun Sun
2000-09-30  0:25   ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000929182640.F16050@bacchus.dhis.org \
    --to=ralf@oss.sgi.com \
    --cc=glonnon@ridgerun.com \
    --cc=linux-mips@fnet.fr \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox