RE: Problems in 2.6 memory management on 8xx

["Joakim Tjernlund" <joakim.tjernlund@transmode.se>]

> -----Original Message-----
> From: Detlev Zundel [mailto:dzu@denx.de] 
> Sent: den 24 maj 2007 18:46
> To: joakim.tjernlund@transmode.se
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Problems in 2.6 memory management on 8xx
> 
> Hi Joakim,
> 
> > On Thu, 2007-05-24 at 17:23 +0200, Joakim Tjernlund wrote:
> >> On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
> >> > Hi,
> >> > 
> >> > working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
> >> > behaviour exemplified by the simple attached demo 
> program.  An icbi
> >> > from userspace on an address that is mapped only lazily 
> gets into an -
> >> > though interruptible - loop. Locking the icbi target in 
> question with
> >> > mlock circumvents this problem.
> >> 
> >> 8xx is buggy w.r.t cache instructions. They do not update the
> >> DAR register in the TLB miss/TLB error handlers.
> >> The TLB miss handler does not use the DAR reg but the TLB error
> >> handler do. Thats why it works when you mlock the memory.
> >> 
> >> This bug isn't documented but Freescale has confirmed it.
> >> You can search the archives some years back for more info.
> >> 
> >>  Jocke
> >
> > BTW, it is possible to workaround this problem in the kernel by
> > tagging DAR with an impossible value and compare DAR against it
> > in the DTLB Error handler. If a match, then do a instruction decode
> > to get the regs involved and calculate the faulting address.
> >
> > I did this several years ago for 2.4 in assembler and posted
> > it, but it was rejected.
> > One should bail out to handle_page_fault and do the
> > calculations there instead(less likely to break that way)
> >
> > Found one version of the patch here:
> > http://patchwork.ozlabs.org/linuxppc/patch?id=1307
> 
> Thanks for shedding some light on this problem.  I already found the
> patch you refer to and also wondered why it was never accepted.  Was
> there a technical reason or did it simply slip everybodys attention?

Can't really rember the details, but I think Dan Malek didn't
like it because it was hard to maintain and usally one can avoid
the problem.
I have been using that patch on our 860/862 boards for years now
and it works fine.

 Jocke