Scott Wood <scottw...@freescale.com> wrote on 11/11/2009 00:21:18: > > Joakim Tjernlund wrote: > > Scott Wood <scottw...@freescale.com> wrote on 10/11/2009 23:02:10: > >> Joakim Tjernlund wrote: > >> It wasn't the CPU15 workaround that I was worried about taking down the > >> pinning -- but rather the CPU15 bug itself causing bad code to be > >> executed inside the pinned kernel mapping. > > > > Oh, but then one is screwed anyway. > > Not if there's a workaround... > > >> However, the erratum says "MMU page", not "4K region", so I suppose if > >> we have a pinned 8M page the problem could only occur at the end of the > >> 8M (by which point the text segment should have ended). > > > > The wording makes me wonder why not a dcbi would fix the problem too. > > Invalidate the problem cache lines and let the branch resolve. > > Where would you put the dcbi? How do you regain control after that > cache line has been refilled, but before code flows back to the bad branch?
The dcbi would replace the current CPU15 tlbie. I would try mitigating bullet 3 (unresolved long enough ...) by invalidating n+1 cache line. Hopefully that will abort the prefetch. If that doesn't work, invalidate n+2(bullet 4) as it says it must be in cache for the problem to manifest. But I see now that I probably misread the errata so the above wont work. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
