linux-mips
[Top] [All Lists]

Re: Malta crashes on the latest 2.4 kernel

To: "Ralf Baechle" <ralf@oss.sgi.com>, "H. J. Lu" <hjl@lucon.org>
Subject: Re: Malta crashes on the latest 2.4 kernel
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Thu, 11 Jul 2002 08:19:55 +0200
Cc: "Jun Sun" <jsun@mvista.com>, <linux-mips@oss.sgi.com>
References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> <20020711043601.B3207@dea.linux-mips.net>
Sender: owner-linux-mips@oss.sgi.com
> On Wed, Jul 10, 2002 at 04:49:00PM -0700, H. J. Lu wrote:
> 
> > > See the crash scene.  Anybody knows the cause?  It is strange to see the 
> > > reserved exception.
> > > 
> > 
> > The 2.4 kernel checked out around Jul  4 09:28 PDT works fine on Malta.
> 
> Jun's patch certainly is correct for some MIPS32 CPUs; others may get
> away without this one.  Previous experience with pipeline hazards on MIPS
> processors has shown that at times hazards may change even between minor
> revisions of a CPU; documentation isn't always trustworthy about such
> minor details of the pipeline.

Excuse me, but I've seen this statement used by others in
the past as an excuse for doing something silly or not doing
something reasonable, and it generally hasn't washed.
In what specific cases have the CP0 pipeline hazards 
changed between minor revisions of any production
MIPS CPU?  The *documentation* may have been
corrected, but these hazards are fairly fundamental
artifacts of the pipeline microarchitecture of a given
processor.

The CP0 hazard between a write of EntryHi
and a subsequent TLBWI instruction is flagged
in the MIPS32 spec and noted as being "typically" 
2 cycles.  I'm not going to spend the time going
through my full set of users manuals, but a representative
sampling shows this hazard as being specified for
every R4xxx and R5xxx CPU I checked.  The fact
that a given CPU *may* get away with it is no
excuse for not protecting common code.

I note that Ralf has, in fact, applied the fix to the
OSS CVS repository.  I also note that "BARRIER"
is still defined to be a string of 6 nops.  I would argue
(again) that those really, really ought to be ssnops,
and that if they *were* ssnops, one could probably
have fewer of them.

            Regards,

            Kevin K.


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