Messages in this thread | | | Date | Mon, 4 Aug 2008 15:26:11 +0200 | From | Mikael Pettersson <> | Subject | Re: Opteron Rev E has a bug ... a locked instruction doesn't act as a read-acquire barrier |
| |
Arkadiusz Miskiewicz writes: > > Hello, > > http://google-perftools.googlecode.com/svn-history/r48/trunk/src/base/atomicops-internals-x86.cc > says > > " // 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. > if (strcmp(vendor, "AuthenticAMD") == 0 && // AMD > family == 15 && > 32 <= model && model <= 63) { > AtomicOps_Internalx86CPUFeatures.has_amd_lock_mb_bug = true; > } else { > AtomicOps_Internalx86CPUFeatures.has_amd_lock_mb_bug = false; > } > " > > does kernel have quirk/workaround for this? I'm looking at arch/x86/kernel/cpu > but I don't see workaround related to this (possibly I'm overlooking).
I can find no reference to this alleged RevE erratum in the Athlon64/Opteron revision guide (25759.pdf).
But if this bug is real then we need to know about it. Could you ask the author of the code you quoted above to clarify?
/Mikael
| |