[Bug 103351] Machine check exception on Broadwell quad-core with SpeedStep enabled

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=103351

--- Comment #86 from Henrique de Moraes Holschuh <hmh@hmh.eng.br> ---
Related information:

Debian will blacklist glibc lock elision (which uses Intel TSX-NI RTM, and does
not use HLE) in Broadwell/Broadwell-H/Broadwell-DE processors.  This could
change, but only if Intel itself decides to own up and publish correct,
consistent information that we feel we can trust.

After all, even the current editions of the Broadwell-* specification updates
are inconsistent with reality.  This makes it impossible to trust Intel TSX-NI
on those processors ATM.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574


Most of the SIGSEGVs observed by users in __lll_unlock_elision are software
bugs (and the bug is NOT in glibc, either): code that attempts to unlock an
already unlocked lock will crash when Intel TSX is being used.

(typical example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750792)

IMO, we should instrument glibc to complain loudly (or even crash) whenever
anything attempts to unlock and unlocked mutex: it will smoke out applications
and libraries with shoddy locking really fast, and shoddy locking is known to
cause subtle, hard to diagnose problems.

The MCE issues are not fixable by anything other than a microcode update, so it
boils down to distros being able to ship that microcode update.

-- 
You are receiving this mail because:
You are the assignee for the bug.