From: Carsten Langgaard <carstenl@mips.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
linux-mips@linux-mips.org, Jun Sun <jsun@mvista.com>
Subject: Re: possible Malta 4Kc cache problem ...
Date: Wed, 04 Dec 2002 21:28:34 +0100 [thread overview]
Message-ID: <3DEE6572.5331C5CD@mips.com> (raw)
In-Reply-To: 20021204173248.GA23213@nevyn.them.org
Could you please tell us, which 4Kc you are running on ?
What are the cache configuration (size, number of ways) ?
Are you running on the latest kernel sources from the CVS tree ?
Have you tried the mips32_cache.h file I send and/or have you tried the kernel
from the ftp.mips.com FTP server ?
Many question at the same time ;-)
/Carsten
Daniel Jacobowitz wrote:
> 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
next prev parent reply other threads:[~2002-12-04 20:29 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
2002-12-04 20:28 ` Carsten Langgaard [this message]
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=3DEE6572.5331C5CD@mips.com \
--to=carstenl@mips.com \
--cc=dan@debian.org \
--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.