8xx v2.6 TLB problems and suggested workaround
marcelo.tosatti at cyclades.com
Wed Apr 6 06:26:04 EST 2005
On Tue, Apr 05, 2005 at 08:41:09AM -0300, Marcelo Tosatti wrote:
> 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.
> How sweet. :)
> > 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.
> Are you sure this is the best solution ?
> Problem is that update_mmu_cache() is called from other context's where
> the tlb invalidate is not necessary (because it has already been invalidated).
> For example all ptep_set_access_flags() (which does the tlb invalidate) ->
> update_mmu_cache() sequences.
> Moreover jumping directly from DataTLBMiss to the page fault handler
> shortcuts the process: there is no need to jump back to execution if we
> know in advance that DataTLBError exception is going to happen.
> But hey, you are the boss. Even with the above facts you prefer
> to leave the DataTLBMiss untouched?
> About size: I think it is the smaller expection handler present.
Well, you know what you're talking about. Whatever you prefer.
Can we just ask someone to send the _tlbie patch around #ifdef CONFIG_M8XX?
More information about the Linuxppc-embedded