How to fix 8xx dcbst bug?

Joakim Tjernlund joakim.tjernlund at lumentis.se
Sun May 8 04:24:01 EST 2005


> 
> 
> 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. 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.

   Jocke

> 
> So, if that is true, can you please merge the update_mmu_cache() fix 
> for the dcbst misbehaviour previously discussed ? 
> 
> Thanks!!



More information about the Linuxppc-embedded mailing list