[glibc] branch sid updated (1f1acab -> 4e62582)

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch sid
in repository glibc.

  from  1f1acab   hurd: fix pt-spin.c build
   new  4e62582   Add bug number

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog | 1 +
 1 file changed, 1 insertion(+)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Processed: Bug#843691 marked as pending

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 843691 pending
Bug #843691 [src:glibc] glibc: FTBFS on ppc64el: Error: operand out of range
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
843691: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843691
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[glibc] 01/01: Add bug number

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit 4e625825c81093eb26537891d4c57561d089a981
Author: Aurelien Jarno 
Date:   Tue Nov 8 22:12:55 2016 +0100

Add bug number
---
 debian/changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/changelog b/debian/changelog
index 93d0f09..82b7346 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,7 @@ glibc (2.24-6) UNRELEASED; urgency=medium
   [ Aurelien Jarno ]
   * debian/patches/git-updates.diff: update from upstream stable branch:
 - Fix pread/pwrite syscalls on SH4.
+- Fix build on powerpc/ppc64el with binutils from trunk.  Closes: #843691.
 - Fix flexible array usage in gconv.h.  Closes: #841304.
 
  -- Aurelien Jarno   Tue, 18 Oct 2016 23:17:42 +0200

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Bug#843691: glibc: FTBFS on ppc64el: Error: operand out of range

[Fernando Seiti Furusato]

Source: glibc
Version: 2.24-5
Severity: serious

Hello,

glibc is failing to build on ppc64el, on sid with the following:

.../sysdeps/powerpc/powerpc64/power6/memset.S: Assembler messages:
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: operand out of range 
(5 is not between 0 and 1)
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: operand out of range 
(128 is not between 0 and 31)
.../sysdeps/powerpc/powerpc64/power6/memset.S:254: Error: missing operand

This was an attempt with sbuild with sid.
It initially built on the same version on buildd, 20 days ago or so,
but the failure was also observed on cross-compilation.

Thanks.

Fernando

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2016, Lucas Nussbaum wrote:
> 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.

IMHO it would be better to instrument the locks in glibc with asserts,
instead.  You could use anything to test for pthread API violations,
then.

That said, if you are going to test Intel TSX for real, you need a
Desktop Skylake-based Core i5/i7 or Xeon E3v5 that reports "RTM" in
/proc/cpuinfo.  Some won't.

Not every Skylake model will have it enabled in the first place, and
apparently the firmware can (and some _do_) disable it, especially on
the mobile side.

Please ensure the Skylake firmware has microcode 0x9d/0x9e or later, or
install the latest version of the non-free intel-microcode package.  The
risk of unpredictable behaviour is quite real otherwise, and could mess
up the test results (and corrupt data).

Skylake errata are a nightmare. Note the AVX, AVX2, eDRAM (L4?), and TSX
ones, as well as the power-management ones:

http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v5-spec-update.pdf
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

Don't attempt to test TSX with perf or intel PT running.  perf is likely
to cause too many aborts, and Intel PT is an errata hell.

As for Broadwell, I don't know which processors would still have TSX
enabled in the first place when running the latest microcode, and we
blacklist most of them in glibc anyway (because almost all Broadwell-*
specification updates list it as either unavailable or unusable), so
they're not a very viable option to test this.

-- 
  Henrique Holschuh

Re: 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)

Answering myself, the relevant patch is
https://sources.debian.net/src/glibc/2.24-5/debian/patches/amd64/local-blacklist-for-Intel-TSX.diff/

Lucas