linux-mips
[Top] [All Lists]

Re: installation problem.

To: Ulf Carlsson <grimsy@varberg.se>
Subject: Re: installation problem.
From: ralf@uni-koblenz.de
Date: Fri, 27 Feb 1998 19:25:53 +0100
Cc: linux@cthulhu.engr.sgi.com
In-reply-to: <Pine.LNX.3.96.980227143143.6574D-100000@calypso.saturn>; from Ulf Carlsson on Fri, Feb 27, 1998 at 02:47:48PM +0100
References: <19980226235300.23817@uni-koblenz.de> <Pine.LNX.3.96.980227143143.6574D-100000@calypso.saturn>
Sender: owner-linux@cthulhu.engr.sgi.com
On Fri, Feb 27, 1998 at 02:47:48PM +0100, Ulf Carlsson wrote:

> > > System: IP22
> > > Processor: 100 Mhz R4000, with FPU
> > > Primary I-cache size: 8 kbytes
> > > Primary d-cache size: 8 kbytes
> > > Secondary cache size: 1024 Kbytes
> > 
> > So this must be a R4000SC CPU.  The CPU support code for it is buggy, that's
> > why it it's working.
> 
> It's _not_ working. And I would like to know why it isn't working.  (ok, I

The exact bug is that one of the cache maintenance routines in
include/asm-mips/r4kcache.h uses there wrong cachop for flushing the
cache.

> understand what you mean, sorry :)  Well, this is not a big problem for me
> anyway. The .68 kernel works. The main problem is the one with the
           
.68 isn't supposed to work.  The memory is laid out such that the buggy
cache routine has a bit less of effect.

> harddrives (detecting them, but with the size of 0Mb, and the kernel can't
> read the partition tables), and the one with the kernel paging request it
> can't handle. Any ideas? 

Should all be the cache effect.

> > Fixes probably coming next week; as think are looking I'll have a hell lot
> > of time again by then.
> 
> Great, next week.. (feels like one year).

Next week starts tonite.  Linux/MIPS industries going back online ...

  Ralf  (Getting coffee and milk ...)

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