On Mar 17, 2009, at 5:38 AM, David Jander wrote:

On Monday 16 March 2009 19:05:00 Kumar Gala wrote:
On Mar 16, 2009, at 10:52 AM, David Jander wrote:
Complete workaround for DTLB errata in e300c2/c3/c4 processors.

Due to the bug, the hardware-implemented LRU algorythm always goes
to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.

Signed-off-by: Kumar Gala <ga...@kernel.crashing.org>
Signed-off-by: David Jander <da...@protonic.nl>

---
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/
head_32.S
index 0f4fac5..3971ee4 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -578,9 +578,21 @@ DataLoadTLBMiss:
        andc    r1,r3,r1                /* PP = user? (rw&dirty? 2: 3): 0 */
        mtspr   SPRN_RPA,r1
        mfspr   r3,SPRN_DMISS
+       mfspr   r2,SPRN_SRR1            /* Need to restore CR0 */
+       mtcrf   0x80,r2
+#ifdef CONFIG_PPC_MPC512x
+       li      r0,1
+       mfspr   r1,SPRN_SPRG6
+       rlwinm  r2,r3,17,27,31          /* Get Address bits 19:15 */

Don't we want:
        rlwinm  r2,r3,20,27,31          /* Get address bits 15:19 */

Hmm, you are right, I must have accidentally counted LE bit- ordering ;-) Only funny part is, that I don't measure any performance difference after
fixing this.... *sigh*.

I wouldn't expect it to. You are picking some bits to hash on. You picked some different bits but the distribution of addresses was probably similiar.

- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to