From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>, "H. J. Lu" <hjl@lucon.org>
Cc: "Jun Sun" <jsun@mvista.com>, <linux-mips@oss.sgi.com>
Subject: Re: Malta crashes on the latest 2.4 kernel
Date: Thu, 11 Jul 2002 08:19:55 +0200 [thread overview]
Message-ID: <005c01c228a2$fb2bf450$10eca8c0@grendel> (raw)
In-Reply-To: 20020711043601.B3207@dea.linux-mips.net
> 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.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralf Baechle <ralf@oss.sgi.com>, "H. J. Lu" <hjl@lucon.org>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@oss.sgi.com
Subject: Re: Malta crashes on the latest 2.4 kernel
Date: Thu, 11 Jul 2002 08:19:55 +0200 [thread overview]
Message-ID: <005c01c228a2$fb2bf450$10eca8c0@grendel> (raw)
Message-ID: <20020711061955.lmM0rm73VDHi970D5_6MRVsMPsdl9yi4QlYwL7A2o_k@z> (raw)
In-Reply-To: 20020711043601.B3207@dea.linux-mips.net
> 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.
next prev parent reply other threads:[~2002-07-11 6:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-10 23:12 Malta crashes on the latest 2.4 kernel Jun Sun
2002-07-10 23:49 ` H. J. Lu
2002-07-11 1:18 ` Jun Sun
2002-07-11 2:36 ` Ralf Baechle
2002-07-11 6:19 ` Kevin D. Kissell [this message]
2002-07-11 6:19 ` Kevin D. Kissell
2002-07-11 6:56 ` Geert Uytterhoeven
2002-07-11 8:35 ` Kevin D. Kissell
2002-07-11 11:45 ` Ralf Baechle
2002-07-11 11:59 ` Ralf Baechle
2002-07-11 7:50 ` Carsten Langgaard
2002-07-11 7:44 ` Carsten Langgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='005c01c228a2$fb2bf450$10eca8c0@grendel' \
--to=kevink@mips.com \
--cc=hjl@lucon.org \
--cc=jsun@mvista.com \
--cc=linux-mips@oss.sgi.com \
--cc=ralf@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox