Scott Wood <scottw...@freescale.com> wrote on 06/11/2009 01:33:05: > > On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote: > > Here is the latest(last?) round of this series. I > > hope I got everything right now. > > Scott and Rex, please test and send ACK/NACK. > > > > Jocke > > > > Joakim Tjernlund (8): > > 8xx: invalidate non present TLBs > > This works, and is an important fix -- it should be applied even if the rest > of the patchset isn't ready.
True. > > > 8xx: Update TLB asm so it behaves as linux mm expects. I think this is ready too. > > 8xx: Tag DAR with 0x00f0 to catch buggy instructions. > > Up through this point works. hmm, here tagging of DAR is in place, do you ever hit the page fault handler with address == 0x00f0? If you do, the kernel somehow manges to fix it instead of erroring out. I do notice one thing, I forgot to add the CPU6 errata to the DAR tagging. Are you using the CPU6 errata? > > > 8xx: Fixup DAR from buggy dcbX instructions. > > With this, the kernel hangs after "Mount-cache hash table entries: 512". Somewhat surprising result. I didn't expect you would even hit this condition now as we haven't enabled the use of dcbX insn yet. The only thing I can think of is the you hit the 0x00f0 due to other dcbX insn use and the kernel managed to fixup this in the page fault handler by pure luck before. The only thing I can thing of being wrong here is your suggested fix: + lis r11, (swapper_pg_dir-PAGE_OFFSET)@h + ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l + rlwimi r11, r10, 22, 0xffc What if you change that back to what worked for you before: lis r11, swapper_pg_...@h ori r11, r11, swapper_pg_...@l rlwinm r11, r11, 0, 0x3ffff000 rlwimi r11, r10, 22, 0xffc or possibly lis r11, swapper_pg_...@h ori r11, r11, swapper_pg_...@l subis r11, r11, page_off...@h rlwimi r11, r10, 22, 0xffc hmm, some missed CPU6 errata calls in DARFixup too. > > > 8xx: Add missing Guarded setting in DTLB Error. > > 8xx: Restore _PAGE_WRITETHRU > > 8xx: start using dcbX instructions in various copy routines > > Once I get up to this patch, it no longer hangs, but I get some user > processes consistently failing with EFAULT. No surprise as the it seems like the DAR decoding is broken. > > > 8xx: Remove DIRTY pte handling in DTLB Error. > > No change after this patch. > > -Scott > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev