Joakim Tjernlund wrote:

Scott Wood [off-list ref] wrote on 17/11/2009 01:40:11:

quoted

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

quoted

quoted

+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 
copy routines" that introduces the problem.

-Scott