From: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
To: Joakim Tjernlund <joakim.tjernlund@lumentis•se>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: How to fix 8xx dcbst bug?
Date: Sat, 7 May 2005 10:57:46 -0300 [thread overview]
Message-ID: <20050507135746.GB16996@logos.cnet> (raw)
In-Reply-To: <JPEALJAFNGDDLOPNDIEECEAKDDAA.joakim.tjernlund@lumentis.se>
On Sat, May 07, 2005 at 08:24:01PM +0200, Joakim Tjernlund wrote:
> >
> >
> > Hi Dan,
> >
> > So, restarting this conversation...
> >
> > On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
> > >
> > > On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> > >
> > > >Problem is that the "dcbst" instruction will, _sometimes_ (the
> > > >failure/success rate is about 1/4
> > > >with my test application) fault as a _write_ operation on the data.
> > >
> > > Oh, geeze .... It's all coming back to me now ....
> > >
> > > The 8xx cache operations don't always operate as defined in the PEM.
> > > There are likely to be some archive discussions within the Freescale
> > > knowledge data base that describe the different behaviors I've seen
> > > with the chip variants and revisions. I can't find any of those e-mail
> > > discussions, so I'll try to recall from memory.
> > >
> > > The PEM cache instructions are all implemented in a microcode that
> > > uses the 8xx unique cache control SPRs. Depending upon the state
> > > of the cache and MMU, it seems in some cases the EA translation is
> > > subject to a "normal" protection match instead of a load operation
> > > match.
> > >
> > > The behavior of these operations isn't consistent across all of the 8xx
> > > processor revisions, especially with early silicon if people are still
> > > using those. During conversations with Freescale engineers, it seems
> > > the only guaranteed operation was to use the 8xx unique SPRs, but
> > > I think I only did that in 8xx specific functions.
> > >
> > > We have way too much code in the TLB exception handlers already,
> > > so let's just try a tlbia of the EA in the update_mmu_cache, with an
> > > #ifdef
> > > for the 8xx.
> >
> > > We may want to make the dcbxxx instructions
> > > some
> > > kind of macro, so on 8xx we can include such operations in otherwise
> > > "standard" software.
> >
> > Now that I think of it, userspace dcbst users should not be an issue
> > because the intermediate invalid TLB entry is not visible to applications.
> >
> > Userspace sees only: not present pte, or valid present pte.
> >
> > Well, at least the entry which has been causing problems,
> > created by DataStoreTLBMiss.
> >
> > Is it safe to assume that dcbst usage on userspace is restricted
> > to valid TLBs? Since MMU SPRs are restricted to supervisor
> > protection, I think so.
>
> Not sure what you mean here. Currently all dcbX instr. in user space
> have to be on valid\populated pte's since otherwise it will SEGV.
OK. The BUG in update_mmu_cache() is triggered because dcbX happens
on populated but invalid page mapping.
> If you write your app so that any dcbX will only cause a plain DTLB you are
> safe, just look at ld.so. This should not be a requirement but for 8xx it is currently and I think 8xx gets
> away with it because nobody is using swap on 8xx.
next prev parent reply other threads:[~2005-05-07 19:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-06 15:45 How to fix 8xx dcbst bug? Marcelo Tosatti
2005-05-07 18:24 ` Joakim Tjernlund
2005-05-07 13:57 ` Marcelo Tosatti [this message]
2005-05-07 18:39 ` Wolfgang Denk
2005-05-07 22:47 ` Joakim Tjernlund
2005-05-08 1:00 ` Dan Malek
2005-05-08 1:10 ` Dan Malek
2005-05-07 21:47 ` Marcelo Tosatti
2005-05-09 19:25 ` Dan Malek
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=20050507135746.GB16996@logos.cnet \
--to=marcelo.tosatti@cyclades$(echo .)com \
--cc=joakim.tjernlund@lumentis$(echo .)se \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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