> > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 28/09/2009 > 05:21:00: > > > > On Sun, 2009-09-27 at 15:22 +0200, Joakim Tjernlund wrote: > > > > However, adding tlbil_va() to ptep_set_access_flags() as you suggested > > > > makes everything happy. I need to test it some more, but it looks good > > > > so far. Below is what I am testing now. > > > > > > 8xx, is getting very hacky and I suspect that the only long term fix is > > > add code to trap the cache instructions in TLB error/miss and fixup the > > > exception in page fault handler. This will also have the added benefit on > > > being able > > > to use the cache instructions in both kernel and user space like any other > > > ppc arch. > > > > First I'd like to understand exactly what's happening today, since > > it makes little sense :-) I suppose I'll have to get myself some > > 8xx doco and understand how the bloody MMU works. > > hmm, I recall that the reason for the currect "force a TLB error" > procedure was to fix a problem Montavista had, possibly Tom Rini. > He fixed the problem differently at first but later it > was changed to what is in use today. > > If you have access to the old linuxppc-embedded you will find a lot > of info in a thread with subject "[PATCH 2.6.14] mm: 8xx MM fix for" > Also I made a ref that I cannot access anymore: > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
Found a link to the original problem http://www.mail-archive.com/linuxppc-embed...@ozlabs.org/msg03376.html seems like I had something to do with the solution that is haunting 8xx now :( Basically 8xx should revert back to the fix suggested in the above link. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
