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

[Joakim Tjernlund]

Scott Wood <scottwood at freescale.com> wrote on 27/10/2009 16:58:41:
>
> 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?

I don't have it for 2.6 and I never did cleanup up my 2.4 version.
Your best bet is to look at one of the earlier patches such
as:
  Add some debug code to do_page_fault
and fix the remaining bits.

> Is the empty TLB entry from the miss getting invalidated in the dcbX fixup
> case?

Yes, in all cases it was invalidated.

>
> > > 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.

Hopefully and I am already looking at the OP code to make sure it is
a dcbX insn.

>
> > 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. :-)

Get yourself a new scheduler :)

   Jocke