This is the mail archive of the mailing list for the libc-ports project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Jun 29, 2011 at 01:08:13PM -0400, Matt Turner wrote:

> > 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.

It's actually not hardlocking but the SC instruction might return success
even though it has failed.  I've tracked this down as the source of
multiple CPUs being able to take the same spinlock resulting in not so
wonderful things happening in the RAID code.

> 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)

It's crude for any modern CPU; the advantage of the NOP solution is that
it would produce binaries that run even on MIPS I processors.

The Linux kernel emulates LL/SC on MIPS I processors which means we have
one construct for atomic operations for ALL MIPS processors; this avoids
the problem of some alternative solutions for MIPS I processors that would
silently fail on multiprocessor systems resulting in crash or corruption.
The performance tradeoff here was clearly made again MIPS I processors
but those have been obsoleted for very long time.

> 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.

There is nothing, at least nothing that is provided by GCC.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]