On Thu, Nov 17, 2016, at 12:12, Adrian Bunk wrote:
> On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh
> wrote:
> > On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> > > But we do already have > 1 year of widespread testing by users
> > > running unstable/testing on machines
On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> > But we do already have > 1 year of widespread testing by users
> > running unstable/testing on machines with TSX enabled.
> >
> > So for unstable/stretch this does
On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> But we do already have > 1 year of widespread testing by users
> running unstable/testing on machines with TSX enabled.
>
> So for unstable/stretch this does not seem to be a huge problem.
>
> These are normal bugs that should be found and
On Thu, Nov 17, 2016 at 09:28:34AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote:
> > On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> > > The deal with *current* Debian stable is that, if the breakage is too
> > > widespread, we
On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote:
> On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> > The deal with *current* Debian stable is that, if the breakage is too
> > widespread, we simply might not be able to do the right thing (fix the
> > real bugs).
>
> Based on
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,
On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> The deal with *current* Debian stable is that, if the breakage is too
> widespread, we simply might not be able to do the right thing (fix the
> real bugs).
Based on the number of bugs uncovered by my archive rebuild, I'm really
not
Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about
pthread locks in stable ?"):
> [stuff]
Thanks for your clear explanations.
> The deal with *current* Debian stable is that, if the breakage is too
> widespread, we simply might not be able to do t
On Wed, Nov 9, 2016, at 06:26, Lucas Nussbaum wrote:
> On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote:
> > I fear it might be bad, but
> > I would love to be pleasantly surprised that people did get libpthreads
> > locking right most of the time...
>
> I wonder if it has been
Am Dienstag, den 15.11.2016, 18:06 +0200 schrieb Adrian Bunk:
>
> > Unfortunately, in current unstable with thread sanitizer one might
> > get #796246 (at least I had this).
>
> Does "-fsanitize=thread -no-pie" work for you?
Indeed, that fixed the problem with g++-6.2 (g++-5.4 doesn't has this
On Mon, Nov 14, 2016 at 10:31:18AM +0100, Gert Wollny wrote:
> Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes
> Holschuh:
> >
> >
> >
> > Unfortunately, when hardware lock elision support was added to glibc
> > upstream, libpthreads was *not* changed to properly assert()
Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes
Holschuh:
>
>
>
> Unfortunately, when hardware lock elision support was added to glibc
> upstream, libpthreads was *not* changed to properly assert() this
> forbidden condition on the non-hardware-elision codepaths. Such an
>
On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote:
> Lucas,
>
> 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
Lucas,
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?
> I've filed bugs for the packages
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.
On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote:
> I fear it might be bad, but
> I would love to be pleasantly surprised that people did get libpthreads
> locking right most of the time...
I wonder if it has been considered to "fix" glibc so that the misuses
that are tolerated
On Tue, Nov 8, 2016, at 15:39, Ian Jackson wrote:
> Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive
> about pthread locks in stable ?"):
> > That said, I am not going to propose any changes to the glibc blacklist
> > at this time, unless new info
Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about
pthread locks in stable ?"):
> That said, I am not going to propose any changes to the glibc blacklist
> at this time, unless new information about how well Intel TSX really
> works in Broadwell bec
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
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.
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
On Sun, 06 Nov 2016, Adam Borowski wrote:
> On Sun, Nov 06, 2016 at 08:02:56PM +, Ian Jackson wrote:
> > Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive
> > about pthread locks in stable ?"):
> > > And what should we do about Debian
On Sun, 06 Nov 2016, Adrian Bunk wrote:
> On Sun, Nov 06, 2016 at 05:41:34PM -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
On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > And what should we do about Debian stretch, then?
>
> I believe a good start would be to add an assert() in a test version of
> glibc and then run all the autopkgtest scripts on the packages
On Sun, Nov 06, 2016 at 08:02:56PM +, Ian Jackson wrote:
> Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about
> pthread locks in stable ?"):
> > And what should we do about Debian stretch, then?
>
> Perhaps we could add the assert you
On 2016-11-06 01:12, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Ian Jackson wrote:
> > Looking at the code, I think that gs in jessie is plainly violating
> > the rules about the use of pthread locks. On my partner's machine,
>
> Per logs from message #15 on bug #842796:
>
[Jeff Epler]
> I believe that similar bugs have been afflicting hurd and kfreebsd
> debian ports for some time. In retrospect, it's too bad these reports
> weren't given more attention, because it could have made things better
> for Linux platforms as well. :-/
Yeah, too bad. :/
On the other
On Sun, Nov 06, 2016 at 05:41:34PM -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
Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about
pthread locks in stable ?"):
> Per logs from message #15 on bug #842796:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15
>
> SIGSEGV on __lll_unlock_elision is a signature (IME with
[resending with correct Cc:]
I believe that similar bugs have been afflicting hurd and kfreebsd debian ports
for some time. In retrospect, it's too bad these reports weren't given more
attention, because it could have made things better for Linux platforms as well.
:-/
see e.g.,
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
On Sat, 2016-11-05 at 20:32 +0100, Christian Seiler wrote:
> On 11/05/2016 08:13 PM, Ian Jackson wrote:
> > I have just been debugging a ghostscript segfault on jessie amd64.
> >
> > Looking at the code, I think that gs in jessie is plainly violating
> > the rules about the use of pthread locks.
[Henrique de Moraes Holschuh]
> And what should we do about Debian stretch, then?
I believe a good start would be to add an assert() in a test version of
glibc and then run all the autopkgtest scripts on the packages in the
archive to see how widespread the problem is. It will not cover all
On Sat, 05 Nov 2016, Ian Jackson wrote:
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks. On my partner's machine,
Per logs from message #15 on bug #842796:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15
SIGSEGV on
On 2016-11-05 19:13, Ian Jackson wrote:
> I have just been debugging a ghostscript segfault on jessie amd64.
>
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks. On my partner's machine,
> this makes it segfault on termination (with
Ian Jackson writes ("libc recently more aggressive about pthread locks in
stable ?"):
> I have just been debugging a ghostscript segfault on jessie amd64.
...
> I recently encountered what seems to be a similar bug in ogg123 in
> stable. #842796.
>
> Has something
On 11/05/2016 08:13 PM, Ian Jackson wrote:
> I have just been debugging a ghostscript segfault on jessie amd64.
>
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks. On my partner's machine,
> this makes it segfault on termination
I have just been debugging a ghostscript segfault on jessie amd64.
Looking at the code, I think that gs in jessie is plainly violating
the rules about the use of pthread locks. On my partner's machine,
this makes it segfault on termination (with some input files, at
least). On my machine it
38 matches
Mail list logo
