On Sun, 11 Feb 2001, Mark Abene wrote:

> 
> I'll recheck the L2 cache code in locore_mips3.S, since I had to make changes
> there to allow for the Magnum SC's 16-byte line size.  You mention there was
> a driver you had to kludge... which driver was it?
> I'd be hesitant to think the cross/mipsel toolchain is at fault, since plenty
> of other people are using it on this list, and the pica and olivetti people
> seem perfectly fine at last check (though the pica code doesn't use the L2
> cache, and the olivetti doesn't have one).
> I still find it suspicious that I panic with "TLB out of universe" if I try
> disabling the L2 cache code.  The panic happens when init is about to start.

Hi Mark,

After spending several days trying to get init to behave when doing the
Magnum 3000 port I know exactly how you feel.   A lot of things need to
happen for it to even load into address space, let along run for you!

What really helps get to the bottom of the problem is to add some
diagnostic code:

1)   Build your kernel with SYSCALL_DEBUG enabled - that will give you a
     bit more info on what the system is upto.

2)   Use poor man checksum's on blocks of memory within the kernel and
     printf the results (memory address & checksum)

     Tap in where you think the problem is happening - I would start
     around sys_execve where the init process is kicked off to check
     the memory loaded for the TEXT segment of init is correct (or doesn't
     change  between reboots which is sounds like it does) 
     Another place to try is at the sonic ethernet or NFS level where the
     file blocks are returned.

     Problem with Demand paged executables is they may not always be
     there all the time, so you might have to excercise some care.

For the record there aren't any surprises in 1.5R running on mips (cannot
speak for the arc port however)

Also FYI - I cross build mipseb binaries using an old version of
cross/mipseb-netbsd every day without any problems on my i386
machine.  For a while I was also cross building on an alpha - That is an
big-endian target generated on a little-endian machine.

You are generating little-endian from a big-endian platform - you may me
in the minority of users doing that.  If you have an i386 you might
want to cross-compile and see if it generates similar results.

My toolchain for cross compiling is currently rather old -
  gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) 
  GNU objcopy 2.9.1

Also - a long shot - check that you are using a full hardware handshake
cable for your console.  When the kernel kicks off init the userland
attempts to open /dev/console using the proper device drivers - I have
seen times when the firmware and kernel require no flow control but the
default ttymodes on the console enable hardware handshake.   Symptoms
sound consistant with your problem so worth mentioning.

Regards,
Wayne