[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.021 / U:41.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site