Comment 9 for bug 739374

For the record, the general consensus on the #ac100 irc channel seems to be:

(1) if you have a mismatched kernel and eglibc, where the kernel has its half of the Android erratum workaround enabled but the libc does not, then you are going to get segfaults (purely as a result of the mismatch and without requiring any kind of hardware bug to manifest itself) if libc tries to do TLS by direct use of the cp15 register. Maverick eglibc was OK because it always deferred to the kernel to do TLS. I believe the segfault Michael reports in comment #7 is this "mismatched libc/kernel" kind.

(2) if you did want to try to work around this bug in a way which didn't require unpleasant and impractical things like "compile everything to avoid the cp15 TLS register", the only approach we could think of was to make eglibc always allocate TLS data such that the value to be stored in the TLS register has bit 20 clear...

(3) ...however, if you have a stock eglibc and a kernel with the erratum workaround disabled/removed, then things seem in practice to work OK. Speculation is that perhaps the erratum is only a problem in marginal situations (eg if the core is very hot).

So what we've ended up doing is disabling the kernel workaround and crossing our fingers.