[PATCH] mips: work-around R10k ll/sc errata

[Matt Turner]

On Wed, Jun 29, 2011 at 12:19 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 29 Jun 2011, Matt Turner wrote:
>
>> Unfortunately, GCC <= 4.6 is going to be around for a while. The patch
>> is noninvasive and only modifies the code in one very specific (and
>> currently broken) case. Would you mind if it were committed, at least
>> until the __sync_*-based implementation is committed?
>
> I didn't get any sense of consensus in the previous discussion (which
> extended to at least Jan 2009) and several people there are rather more
> expert in the MIPS variants than me.  Perhaps someone would care to put
> together a compilation of all the points raised and explain how the patch
> addresses them or at least leaves things no worse off - in particular
> detailing the circumstances (compiler options) under which the patch
> results in any change to the code in glibc.

The problem I aim to solve is a silicon bug in early revisions of
SGI's R10k CPU, used in Origin 2xx and Indigo2 systems. The problem
manifests as ll/sc causing the system to hard lock.

The previous patch from a couple of years ago tried to modify
atomics.h so that no matter how you compiled the code, it would be
safe for R10k, even if it meant padding with 28 nops (in order to be
able to ship the same binaries for both systems affected and
unaffected. I don't want to do this)

gcc-4.4 includes R1{0,2,4,6}k scheduler support through the
-march=r1{0,2,4,6}k flag. The patch I've submitted takes advantage of
the fact that gcc defines _MIPS_ARCH_R10000 when invoked with
-march=r10k/-march=r10000. When _MIPS_ARCH_R10000 is defined, the beqz
instruction following a sc instruction is replaced with beqzl, working
around the deadlock. gcc also exposes an -mfix-r10000 flag, but it
does not define any preprocessor directives, otherwise the patch would
rely on it.

For all other -march= options, the code remains unaffected.

Thanks. I hope this makes things more clear.
Matt