Re: libc recently more aggressive about pthread locks in stable ?
On Sun, Nov 13, 2016, at 14:42, Lucas Nussbaum wrote:
> On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote:
> > Thanks for trying a build run with TSX enabled.
> >
> > On Sat, 12 Nov 2016, Lucas Nussbaum wrote:
> > > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
> > > use a CPU with TSX enabled.
> >
> > What microcode revision is that Xeon E5-2686 running?
>
> microcode: CPU0 sig=0x406f1, pf=0x1, revision=0xb000014
This is quite outdated, and it is in fact below the minimum recommended
revision for Linux use (as defined by "whatever Intel is distributing in
the latest Linux public microcode distribution" [1]). I wouldn't trust
it for general production work, unless we're talking a distributed
application built upon resilient nodes and resilient inter-node result
cross-checking. Kinda cloudy, I suppose :-)
Note that I don't think at all that it invalidates any results you got
about buildability under TSX. It is just a reminder of yet another
reason to never trust the cloud too much.
It is also a reminder to ensure all of our (Debian) boxes are running
the latest relevant firmware update level and have the intel-microcode
package from stable non-free installed.
[1] Which is, as of 2016-11-04:
sig 0x000406f1, pf_mask 0xef, 2016-10-07, rev 0xb00001f, size 25600
In a couple months[2], it will migrate to Debian stable, which currently
has:
sig 0x000406f1, pf_mask 0xef, 2016-06-06, rev 0xb00001d, size 25600
[2] I enforce an one month quarantine in Debian testing before I even
submit a stable p-u request, and that one will typically sit in s-p-u
for a while (after it is approved) until the next stable point release
is out. Anyone that needs it earlier can get it from stable-backports. I
should upload the stable backport of intel-microcode 3.20161104-1 before
this weekend.
--
Henrique de Moraes Holschuh <hmh@debian.org>
Reply to: