[lkml]   [2009]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2/2] x86 amd fix cmpxchg read acquire barrier
* Ingo Molnar ( wrote:
> * Mathieu Desnoyers <> wrote:
> > " // Opteron Rev E has a bug in which on very rare occasions a locked
> > // instruction doesn't act as a read-acquire barrier if followed by a
> > // non-locked read-modify-write instruction. Rev F has this bug in
> > // pre-release versions, but not in versions released to customers,
> > // so we test only for Rev E, which is family 15, model 32..63 inclusive.
> Dunno. The fix looks a bit intrusive (emits a NOP even on good
> CPUs). Also, the text above says "not in versions released to
> customers".
> So unless there's an official erratum or reports in the field (not
> from early prototype systems shipped to developers) i'd not rush to
> apply it, just yet.

Actually, Operon Rev E has this bug in the field (family 15, model
32..64). Rev F only had the bug in pre-releases.

But yes, it's bad that it drags so many code additions to something as
critical as cmpxchg. I start to think it might be better to just
disallow bringing up more than one CPU on these machines.


> Ingo

Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68

 \ /
  Last update: 2009-04-23 15:23    [W:0.098 / U:2.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site