[PATCH 0/8] Fix 8xx MMU/TLB

[Scott Wood]

On Tue, Oct 27, 2009 at 10:16:17AM +0100, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 27/10/2009 01:00:53:
> >
> > On Mon, 2009-10-26 at 16:26 -0700, Dan Malek wrote:
> > > Just be careful the get_user() doesn't regenerate the same
> > > translation error you are trying to fix by being here......
> 
> yes, I had some problems with this initially but managed to work around
> that. I noticed another problem though, I got multiple TLB errors for the
> same address when I did it in C. Noticed by just printk:ing every hit for
> a dcbX insn in do_page_fault. I can't explain it, but it seems like when
> moving to C you have to execute a rfi insn and that might somehow restart
> the dcbX insn before moving on to the page fault routine(or something
> totally different)

The rfi should be to other kernel code -- there is no way that it should be
restarting the dcbX (other than when trying to turn a TLB miss into a TLB
error).  Can you post the C version, maybe we can see what's going wrong? 
Is the empty TLB entry from the miss getting invalidated in the dcbX fixup
case?

> > It shouldn't since it will always come up with a proper DAR but
> > you may want to double check before hand that your instruction
> > address you are loading from is -not- your marker value for bad DAR.
> 
> hmm, I check that the insn really is a dcbX insn, but not that the address is
> != 0x00f0. Don't see how it could be as if something is wrong with
> the insn address you get ITLB error instead of a DTLB error.

I'm guessing he meant the data address you're loading.

> Anyhow, things seems stalled as I haven't heard from Scott or Rex for a
> while. If this isn't working now, I really don't know what is wrong and
> need some debugging help.

I'll test the latest version, but I have some scheduling latency. :-)

-Scott