Scott Wood <scottw...@freescale.com> wrote on 10/11/2009 00:00:04: > > On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote: > > On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote: > > > > > 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. > > > > It's bizarre -- it still happens even if I revert the branch to FixupDAR. > > However, if I comment out the final "b 151b", it stops happening. It also > > stops happening sometimes depending on where I stick printk()s to debug > > this. > > > > So it may be an unrelated issue that just got perturbed somehow. > > OK, figured it out. The fixup code pushed things around so that in
Cool! > syscall_exit_cont, SRR0/SRR1 were being loaded immediately prior to a page > boundary, with the rfi after the page boundary. On crossing the boundary, > we take an ITLB miss (which goes from possibility to certainty with the > CPU15 workaround), and SRR0/SRR1 get clobbered. I am not familiar with CPU15 since we never had that problem. The patch series is OK then, but one need to add some CPU15 love? > > I suppose we'll need to find all places where we do rfi with the MMU > enabled, and ensure acceptable alignment. :-( Ouch, but it can't be that many places though. > > Either that, or require that the kernel text be pinned, though that does not > interact well with CPU15. Why does not pinning interact well with CPU15? If pinned, you never get a TLB miss for kernel text so that should mitigate the CPU15 problem. Jocke _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev