Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Lucas Nussbaum]

On 07/11/16 at 21:52 +0100, Lucas Nussbaum wrote:
> Hi,
> 
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> How can one know what glibc does on a given CPU? (preferably without
> access to the hardware)
> 
> I could try to run an archive rebuild on hardware where glibc leverages
> TSX to see what happens.

I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
use a CPU with TSX enabled.

I've filed bugs for the packages that failed during that rebuild, but
don't fail on m4.large instances:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-ftbfs-20161111;users=debian-qa@lists.debian.org

It's not impossible that some of them are caused by problems with
building in parallel, unrelated to TSX.

L.