Re: libc recently more aggressive about pthread locks in stable ?
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.
Reply to: