Subject: Re: 2.0.35 for Brutus

From: Nicolas Pitre <[email-masked]>
Date: Tue, 15 Sep 1998 17:44:42 -0400 (EDT)

On Tue, 15 Sep 1998, Alex Holden wrote:

> On Mon, 14 Sep 1998, Nicolas Pitre wrote:
> 
> > rc.sysinit: memory violation at pc=0x00000000, lr=0x6001f950 (bad
> > address=0x000)
>         ^ Beware the path of the null pointer for therein lies madness ;)
> 
> > Does someone can tell me what's wrong?
> 
[...]
> Then again, to have got to the stage of trying to execute rc.sysinit, it
> must have first loaded init, linked it against the various libraries it
> needs (including libc), run it, opened /etc/inittab, and read up to the
> point where it tells it to run rc.sysinit (which would seem to be a good
> sign that it at least got that far before fouling up).

You're absolutely right!

> What about creating a program /etc/init which simply dumps the contents
> of /dev/ram0 to /dev/ttyS0 or something to dump the ramdisk image out to a
> serial port. If it fails part way through, you know it has a problem
> accessing the ramdisk. If it manages to send it all, you can run e2fsck
> on it to find out if it has become corrupted at some point.

The same ramdisk image is OK with 2.0.30.  If it gets corrupted it's after
the kernel is booted otherwise the decompression would fail.

> You could also try deleting /sbin/init and creating a blank /etc/rc file,
> if you're lucky you'll end up with an absolute bare bones root shell, from
> which you can try entering commands until you hit on something which makes
> it die. CTRL-ScrollLock and the proc filesystem could be your friends

What I just tried is ln -s /bin/sh /sbin/init and I actually got a shell
prompt!  I can even start /bin/bash.  The echo command works but it's
probably the bash's internal echo.  But when I execute a command link ls,
I get ls to list the files and then boom.  The terminal sometimes displays
segmentation fault, sometimes it don't.  And at that moment, the console
is displaying this over and over:

init: memory violation at pc=0x03fffe60, lr=0x2002d728 (bad
address=0x03fffe60,)

It does the same thing whatever command I give it.  It seems something
is wrong with the exit code or such...  

At one time I got:

[1] init: branch through zero
Internal error: Oops: 0
CPU: 0
pc : [<00000004>]
lr : [<2002d728>]
sp : bffffe08  ip : 00000000  fp : 00000000
r10: 00000000  r9 : c000a7f8  r8 : 00000093
r7 : 00000050  r6 : c0081040  r5 : 00000000  r4 : 00000002
r3 : c0078ad0  r2 : 00000000  r1 : 00000001  r0 : d83e4070
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Process init (pid: 1, stackpage=c00fb000)
Stack:
Code: pc not in code space

BTW: the ramdisk image is made up of a.out binaries, from the great work
from the Itsy team.

Again, does someone have a clue?
Did other people had similar problem with 2.0.35?

Thanks to everione who responded!

Nicolas Pitre, B. ing.
[email-masked]

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Alex Holden <[email-masked]>
Date: Wed, 16 Sep 1998 18:01:29 +0100 (BST)

On Tue, 15 Sep 1998, Nicolas Pitre wrote:
> probably the bash's internal echo.  But when I execute a command like ls,

Or the context switch... cache coherency?
What happens if you run something in the background (something which 
doesn't exit) eg. cat /dev/zero > /dev/null &

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :