The attached patch adds a workaround for R10000 CPUs to use the branch
likely (beqzl) instruction in atomic operations, because revisions of
the CPU before 3.0 misbehave, while revisions 2.6 and earlier will
deadlock. This issue has been noted on SGI IP28 (Indigo2 Impact R10000)
systems and SGI IP27 Origin systems.

I drafted it after some discussion with several people in the Linux/MIPS
IRC Channel after discovering glibc didn't work quite right on my IP28
machine. The patch is based on Debian bug #462112, viewable here:

Feedback would be welcome on any suggestions for improving this patch
(please CC, as I'm not subscribed to the ML).

Had a typo in my original patch w/ some stray parenthesis. A fixed patch is
attached.

I've wondered this on the equivalent patch on the gcc-patches ML as well, on
whether this check should be strictly limited to when -march=r10000 is passed to
the compiler. I think -march=mips4 is probably better, but would having beqzl
used even when -march=mips2, which is the ISA level that added branch likely, be
even better?

--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."