This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17351] No hardware with functional lock elision available
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 05 Sep 2014 17:42:17 +0000
- Subject: [Bug nptl/17351] No hardware with functional lock elision available
- Auto-submitted: auto-generated
- References: <bug-17351-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17351
--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Cedric BAIL from comment #2)
> Did you choose to force the microcode update on Redhat ? If not how do you
> advise user who have random crash and have absolutely no clue where to look
> ?
Please contact Red Hat support for an answer to this question.
No RHEL glibc enables lock elision.
> I don't know if you know, but rust has build a work around this bug to
> prevent bug from happening on software build with it :
> https://github.com/rocallahan/rr/commit/
> d389eb724a9b5f895f813600d9276e00dc063068 .
That isn't a workaround for the errata.
Rust is disabling elision in glibc for their own reasons, it isn't disabling
elision in general. Other applications will continue to check the cpuid RTM bit
and use elision.
You as a user must make an informed choice to update or not update the
microcode for the errata issue.
And Fedora glibc will continue to support those users that wish to use RTM on
those CPUs.
--
You are receiving this mail because:
You are on the CC list for the bug.