linux-mips
[Top] [All Lists]

Re: Help with OOPSes, anyone?

To: Matthew Dharm <mdharm@momenco.com>
Subject: Re: Help with OOPSes, anyone?
From: Jason Gunthorpe <jgg@debian.org>
Date: Sun, 27 Jan 2002 03:53:34 -0700 (MST)
Cc: linux-mips@oss.sgi.com
In-reply-to: <20020127002242.A11373@momenco.com>
Reply-to: Jason Gunthorpe <jgg@debian.org>
Sender: owner-linux-mips@oss.sgi.com
On Sun, 27 Jan 2002, Matthew Dharm wrote:

> My instincts are telling me that these are all being caused by the same
> problem, but I'll be damned if I can figure out what that is.  Caching is a
> good suspect, but that's just because it's always a good suspect.

I can tell you that I have managed to get 2.4.17 (patched up from the
2.4.15 in the linux_2_4 branch of SGI CVS) running very solidly on a
RM7000 platform. I have carefully inspected the cache code, and I
think that what is in the CVS tree is correct, though a little
over-zealous :> I had to make some tweaks to the cache init on the RM7k,
the existing code is wrong - but this is only important if your PROM does
not do it for you. I can send you this code if you like.

I'm using the Debian user land, 8M of L3 and a custom system controller.
The machine works will enough to build complicated programs, run X stuff,
etc. My board also has 512M of ram, (mapped from 0-512M, so no problems
with highmem..). The box is nfs root'd and I've currently got a 8139
ethernet chip on it. 

> In these OOPSes, one is caused by some code in unaligned.c -- I've seen
> several (many) like this, tho I only captured and decoded one.  The code in

Many of the oops's I've seen (while gettings this working) come from
unaligned.c - haven't investigated why yet - they might actually be kernel
unaligned memory references.

While working on the SR7100, I noticed that various sorts of problems that
result in a subtly broken system bus caused random faults in unaligned.c

> -- I FTPed the SRPM for wget and built it without any problems.  Heck, it
> even works!  But when I try to build something bigger (say, ncftp or
> glibc), it dies an ugly death.  Heck, I could FTP, build, and use ksymoops

Just tried for you:

mips:/tmp/ram# apt-get source -b ncftp
[..]
dpkg-deb: building package `ncftp' in `../ncftp_3.1.1-3_mipsel.deb'.
mips:/tmp/ram# uname -a
Linux mips 2.4.15-greased-turkey #407 Thu Jan 17 19:20:18 MST 2002 mips unknown
mips:/tmp/ram# cat /proc/cpuinfo    
processor               : 0
cpu model               : RM7000 V3.2  FPU V2.0
BogoMIPS                : 346.20
[..]
mips:/tmp/ram# free
             total       used       free     shared    buffers     cached
Mem:        514100     124996     389104          0         16      98604

> hopes that will fix the problem.  I'm thinking about trying
> CONFIG_MIPS_UNCACHED, but I don't know if that works on an RM7000 processor

It does.

> -- the L1 and L2 are built-in to the processor, and I don't think the L1
> can be deactivated.  Then again, I don't know how CONFIG_MIPS_UNCACHED

They can.. It is worth trying without the L3 cache at the very least.

I see your boards have the GT system controllers. You may want to validate
they are configured correctly, you can get all sorts of really screwy
results if they are not - there are lots of errata for those chips, and 
some models have a very intolerant (electricaly) sdram controller.

Jason





<Prev in Thread] Current Thread [Next in Thread>