[Bug nptl/17351] No hardware with functional lock elision available

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |carlos at redhat dot com
         Resolution|---                         |INVALID

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Cedric BAIL from comment #0)
> Intel has found an issue in the lock elision micro code and is rolling out a
> microcode that disable it apparently for older haswell.
> 
> http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-
> haswell-early-broadwell-cpus
> http://anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-
> in-haswell-haswelleep-broadwell
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-
> updates/xeon-e3-1200v3-spec-update.pdf
> 
> People who did not update their microcode will have some weird/random issue
> most likely when using a glibc build with elision. Arch Linux has concluded
> it is not a software bug and it doesn't require to change their packaging
> (https://bugs.archlinux.org/task/39631).

I agree, it is not a software bug. Fedora will continue to ship with lock
elision enabled.

> Please advise what is the proper solution to this problem, as it potentially
> affect a lot of people who wont know where the problem come from.

The soultion is to apply the microcode update. This will disable RTM in cpuid
and disable elision use in glibc.

If you choose not to update your microcode you can do so, and keep using RTM,
but may run into the corner case described in the errata.

Cheers,
Carlos.

-- 
You are receiving this mail because:
You are on the CC list for the bug.