linux-mips
[Top] [All Lists]

Re: CVS Update@-mips.org: linux

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: CVS Update@-mips.org: linux
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 3 Apr 2003 16:24:29 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.3.96.1030403154337.19058E-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Apr 03, 2003 at 04:11:02PM +0200
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20030403133610Z8225197-1272+1139@linux-mips.org> <Pine.GSO.3.96.1030403154337.19058E-100000@delta.ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5.1i
On Thu, Apr 03, 2003 at 04:11:02PM +0200, Maciej W. Rozycki wrote:

>  Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
> #5.  But then it applies to V3.0, too.
> 
>  Then the bit is r/w, so how about toggling it instead of panicking? 
> With an informational message like:
> 
> printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
> the R4000...\n");
> printk(KERN_ERR "... fixing up to 16-byte size.\n");
> 
> Of course that probably requires a temporary cache inhibition and
> invalidation.

I know of one machine where changing the size of the cacheline is supposed
not to work, that's the MIPS Magnum 4000 and it's close relatives.

Anyway, I put the check there for the unlikely case there are broken
systems out there.  In practice I assume vendors were aware of this
problem and the check is purely theoretical and for paranoid correctness's
sake.

It seems like changing the configuration to larger cache lines where
possible should improve performance somewhat.  If all the cache code is
working truly correct we also should no longer see VCE exceptions on
R4000SC processors - the reason why Indys are still a valuable test tool.

  Ralf

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