[PATCH 00/10] Fix 8xx MMU/TLB

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Nov 19 08:45:45 EST 2009


Scott Wood <scottwood at freescale.com> wrote on 18/11/2009 22:08:24:
>
> Joakim Tjernlund wrote:
> > Scott Wood <scottwood at freescale.com> wrote on 17/11/2009 01:40:11:
> >> No...  I only meant that the ITLB pinning got rid of the boot hang.
> >>
> >> When I mentioned the EFAULTs before you said, "No surprise as the it
> >> seems like the DAR decoding is broken."  I thought you meant you'd found
> >> a bug and fixed it in this respin.
> >
> > Oh, there seems to be a misunderstanding here :)
> > Lets go back a bit, you said some time ago:
> > /Quote
> >>> +3:   lwz   r11, 0(r11)       /* Get the level 1 entry */
> >>>       DO_8xx_CPU6(0x3b80, r3)
> >>>       mtspr SPRN_MD_TWC, r11       /* Load pte table base address */
> >>>       mfspr r11, SPRN_MD_TWC       /* ....and get the pte address */
> >>>       lwz   r11, 0(r11)       /* Get the pte */
> >>>       /* concat physical page address(r11) and page offset(r10) */
> >>>       rlwimi      r11, r10, 0, 20, 31
> >> But r10 here contains SRR0 from above, and this is a data TLB error.
> >
> > Never mind that last one, forgot that you'd be wanting to load the
> > instruction. :-P
> >
> > But the rlwimi is what's causing the machine checks.  I replaced it with:
> > rlwinm       r11, r11, 0, 0x3ffff000
> > rlwimi       r11, r10, 22, 0xffc
> >
> > and things seem to work.  You could probably replace the rlwinm by
> > subtracting PAGE_OFFSET from swapper_pg_dir instead.
> > /End Quote
> >
> > I read this as now everything is working, but I guess I misunderstood?
> > You still have EFAULT here?
>
> Ah, that one -- I don't recall whether it was fully working back then, or
> whether I just didn't notice the EFAULTs and was commenting more on the machine
> checks going away.
>
> In the current patchset, it's "8xx: start using dcbX instructions in various

Yeah, those are the ones that will trigger a dcbX TLB fault,
copy_tofrom_user would be my guess. Perhaps I missed something
in the conversions? That is, maybe some of these routines are plain wrong now for
8xx due to some other bug?
A small test program in user space doing some dcbX insn could shed some light?



More information about the Linuxppc-dev mailing list