All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Carsten Langgaard <carstenl@mips.com>,
	linux-mips@linux-mips.org, Jun Sun <jsun@mvista.com>
Subject: Re: possible Malta 4Kc cache problem ...
Date: Wed, 4 Dec 2002 12:32:48 -0500	[thread overview]
Message-ID: <20021204173248.GA23213@nevyn.them.org> (raw)
In-Reply-To: <021401c29bb7$cd02abe0$10eca8c0@grendel>

On Wed, Dec 04, 2002 at 06:08:22PM +0100, Kevin D. Kissell wrote:
> > > I think that Carsten's patch (or equivalent) should certainly be
> > > applied to the main tree, but I wonder how relevant it is here.
> > > The flushes associated with trampolines don't do indexed
> > > flush operations, do they?
> > 
> > True, but are we sure that it's the trampoline that's the problem here?
> 
> Jun Sun seemed to think it was. To quote his original message
> 
> "The problem involves emulating a "lw" instruction in cp1 branch delay
>  slot, which needs to  set up trampoline in user stack.  The net effect
>  looks as if the icache line or dcache line is not flushed properly."
> 
> I don't know what his actual observations were that lead to that
> conclusion, but the resemblence to what was reported under LTP
> with the pre-break_cow()-patch kernel intrigues me.

Here's some of the actual observations: if you single-step over the
bc1t instruction, then it comes out as you'd expect; the load in the
delay slot was executed.  Even if you breakpoint in the general
vicinity and then continue.

But if you breakpoint _after_ the instruction, it is evident that the
load did not occur as expected.

> So, I repeat... 
> > > ...I don't have a 4Kc platform at
> > > hand, but I think that Jun Sun *may* have found a better
> > > way to get at the other problem I was referring to, which
> > > we rarely saw on non-superscalar issue CPUs, and which
> > > seems to be masked by an otherwise superfluous flush of
> > > the Icache that was added to the latest versions of break_cow().
> > > If Carsten's patch solves the problem without applying that
> > > other update, I'd want to know that.  If it *doesn't*, I'd be
> > > really interested to know if, by any chance, there is a
> > > corelation between failures of Jun Sun's test and the incidence
> > > of page faults on the CACHE op in protected_icache_invalidate_line().
> > >
> > >             Kevin K.
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2002-12-04 17:32 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-04  6:45 possible Malta 4Kc cache problem Jun Sun
2002-12-04  9:38 ` Kevin D. Kissell
2002-12-04  9:38   ` Kevin D. Kissell
2002-12-04  9:46   ` Kevin D. Kissell
2002-12-04  9:46     ` Kevin D. Kissell
2002-12-04 10:08   ` Carsten Langgaard
2002-12-04 11:21     ` Carsten Langgaard
2002-12-04 13:06       ` Kevin D. Kissell
2002-12-04 13:06         ` Kevin D. Kissell
2002-12-04 13:14         ` Carsten Langgaard
2002-12-04 13:28           ` Carsten Langgaard
2002-12-04 17:08           ` Kevin D. Kissell
2002-12-04 17:08             ` Kevin D. Kissell
2002-12-04 17:32             ` Daniel Jacobowitz [this message]
2002-12-04 20:28               ` Carsten Langgaard
2002-12-04 22:58                 ` Jun Sun
2002-12-05  9:38                   ` Carsten Langgaard
2002-12-06 16:42                     ` Maciej W. Rozycki
2002-12-06 22:24                       ` Hartvig Ekner
2002-12-06 22:24                         ` Hartvig Ekner
2002-12-09 10:51                         ` Dominic Sweetman
2002-12-09 10:51                           ` Dominic Sweetman
2002-12-04 22:19     ` Jun Sun
2002-12-05  9:27       ` Kevin D. Kissell
2002-12-05  9:27         ` Kevin D. Kissell
2002-12-04 21:59   ` Jun Sun
2002-12-04 23:14     ` Kevin D. Kissell
2002-12-04 23:14       ` Kevin D. Kissell
2002-12-04 22:53 ` Jun Sun

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=20021204173248.GA23213@nevyn.them.org \
    --to=dan@debian.org \
    --cc=carstenl@mips.com \
    --cc=jsun@mvista.com \
    --cc=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.