The pointer to the test case was given here before.
Oh, I missed that. Anyway, I wanted to see the asm, and who knows,
with different compiler versions and all that.
0x10000984 <child_thread+52>: bl 0x10001750 <sleep>
0x10000988 <child_thread+56>: lis r9,4097
---> 0x1000098c <child_thread+60>: stw r29,7792(r9)
0x0000000010000d4c <child_thread+60>: bl 0x10000a88
0x0000000010000d50 <child_thread+64>: ld r2,40(r1)
0x0000000010000d54 <child_thread+68>: ld r9,-32688(r2)
---> 0x0000000010000d58 <child_thread+72>: std r29,0(r9)
In both these cases, the storage access goes to LSU0, so you're
not hitting the errata.
I noticed set_dabr() doesn't do proper synchronisation insns, could
you try this patch? I doubt it helps, but it changes the code to do
"the right thing".
diff --git a/arch/powerpc/kernel/process.c
b/arch/powerpc/kernel/process.c
index 4846bf5..ee925f5 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -250,7 +250,9 @@ int set_dabr(unsigned long dabr)
/* XXX should we have a CPU_FTR_HAS_DABR ? */
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
+ asm("sync");
mtspr(SPRN_DABR, dabr);
+ asm("isync");
#endif
return 0;
}
(badly copy/pasted, please apply by hand. Will send a real patch later
;-) )
If this doesn't help, and the failures stay intermittent, I don't think
there
is a close-to-the-hardware problem here.
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
