On Fri, 11 Mar 2011, Martin Zobel-Helas wrote:
On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote:
I was prodded by my Chilean friend, Germán Póo-Caamaño, to help find a
way to push the tzdata corrections needed for Chile's change of
timezone plans. Trying to do so, I found he already
On Fri, 11 Mar 2011, Adam D. Barratt wrote:
On Fri, 2011-03-11 at 16:54 -0300, Henrique de Moraes Holschuh wrote:
On Fri, 11 Mar 2011, Martin Zobel-Helas wrote:
On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote:
Chile was supposed to leave the Summer daylight savings period
Package: libc-bin
Version: 2.11.3-2
Severity: minor
(verified to also apply to 2.13-26)
Manpage gai.conf(5) is missing the description of scopev4, which makes it
even more painful to deal with RFC3484 and gai.conf...
I've found a slightly improved manpage here:
Package: glibc
Severity: wishlist
It is nearly impossible for an user to understand what the hell Servname
not supported for ai_socktype means. Please at least change that to
Socket service name unknown, or something else that makes sense to someone
who DOES NOT write Unix socket code...
--
On Tue, 30 Nov 2004, GOTO Masanori wrote:
At Wed, 17 Nov 2004 21:20:09 -0200,
Henrique de Moraes Holschuh wrote:
It is nearly impossible for an user to understand what the hell Servname
not supported for ai_socktype means. Please at least change that to
Socket service name unknown
Package: glibc
Severity: normal
argp options marked as OPTION_DOC are displayed (with the leading --, even)
on --usage output. This does not make sense, these are not to be treated as
options by the parser, so they certainly should not be displayed by --usage,
let alone with the unexistent
On Thu, 02 Feb 2006, Lionel Elie Mamane wrote:
I just realised that the timezone data in glibc is taken from an
upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data
sometimes changes, more rapidly than our release cycle (and than any
release cycle we can reasonable have).
See
On Thu, 16 Mar 2006, Aurelien Jarno wrote:
Well I am currently trying to split the glibc to not have libraries and
binaries in the same package (that will be a problem for multiarch).
While I am doing that, I can also put the timezone data in a separate
package.
Please do. That will be a
Package: libc6
Version: 2.19-0experimental0
Severity: grave
Justification: causes non-serious data loss
libpthread-2.19 has HLE (hardware-assisted lock elision) support.
Unfortunately, on Intel-based x86 processors, the use of HLE is currently
hazardous.
Summary: Use of HLE on all current Intel
On Fri, 19 Sep 2014, Aurelien Jarno wrote:
It looks like Intel did crap there, and that the GNU libc has to handle
this crap. The microcode update could have stop advertising the
instructions while still supporting them...
They had their reasons to not do it that way, I suppose. I don't think
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
I can live with that, and I think I can prepare a patch if you want me to.
Here's a minimal patch to glibc that should do it (compile tested).
This minimal patch does not give the local admin any way to override the
Intel TSX blacklist. I
On Fri, 19 Sep 2014, Carlos O'Donell wrote:
On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
I can live with that, and I think I can prepare a patch if you want me to.
Here's a minimal patch
On Sat, 20 Sep 2014, Carlos O'Donell wrote:
On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Fri, 19 Sep 2014, Carlos O'Donell wrote:
On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Fri, 19 Sep 2014, Henrique
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
On Fri, 19 Sep 2014, Carlos O'Donell wrote:
On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
I can live with that, and I think I can prepare
On Mon, 29 Sep 2014, Henrique de Moraes Holschuh wrote:
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
Apparently there's at least one codepath that attempts to use lock elision
regardless of --enable-lock-elision in x86 in rwlock. I'm searching for it.
Indeed it looks like glibc
On Thu, 16 Oct 2014, Carlos O'Donell wrote:
I disagree. IMO the most flexible approach is for glibc to stop using cpuid
for RTM detection and rely on the kernel to tell it if RTM is usable. Then
we have a single hardware blacklist in the kernel. We need to talk to
kernel people about this. Not
On Tue, 21 Oct 2014, Aurelien Jarno wrote:
On Thu, Oct 16, 2014 at 07:49:29PM -0400, Carlos O'Donell wrote:
I disagree. IMO the most flexible approach is for glibc to stop using cpuid
for RTM detection and rely on the kernel to tell it if RTM is usable. Then
we have a single hardware
plans for uploading new glibc to unstable are.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> > Broadwell-H with a very recent microcode update (rev 0x12, from
> > 2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
> > enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV.
> > An even more recent Broadwell-H
On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> > Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> > provide for a possible long-term plan to fine-tune the lock-elision
> > blacklist (and anyth
of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
Intel TSX is broken on Haswell based processors (erratum HSD136/HSW136)
and a microcode upd
Package: libc6
Version: 2.19-4
Severity: grave
Justification: causes non-serious data loss
Intel Broadwell-H and Skylake-S/H have critical errata that causes HLE
to be extremely dangerous to use on those processors, resulting in
unpredictable behavior (i.e. process crashes when you are lucky,
o that we can get
independent reports of the HLE situation in Skylake.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Thu, 01 Oct 2015, Henrique de Moraes Holschuh wrote:
> We have a fix for the HLE BDW50 errata confirmed for Broadwell-H,
> through updated microcode.
>
> Broadwell-H errata BDW50 fix:
> signature 0x40671, pf_mask 0x22, revision >= 0x12
>
> Which would allow us to se
Looks like the usual lock b0rkage where something tries to unlock an
already unlocked lock, to me. In that case, it is a simple software
bug.
However, if (and only if) it only happens under x32, but works fine
under amd64 on the same box, it could be a bug somewhere else (kernel,
libpthreads,
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, 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 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
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 micr
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
d generate a warning instead.
That said, I am not speaking against disabling hardware lock elision
acceleration for Debian Stretch. We might be better off disabling it.
--
Henrique de Moraes Holschuh <h...@debian.org>
On Thu, 05 Jan 2017, Aurelien Jarno wrote:
> On 2017-01-05 09:15, Henrique de Moraes Holschuh wrote:
> > Also valid for S/390x, POWER, and anything else where glibc 2.24
> > supports hardware lock elision.
>
> Do you have some pointers about the different behaviour of lock
Package: libc6
Version: 2.24-11+deb9u2
Severity: important
This seems to be a regression in the stretch-proposed-updates release
2.24.11+deb9u2, at least I did not observe it when going
jessie->stretch, or in the 2.24.11->2.24.11+deb9u1 update.
And yes, I am sure the file was created by
Now attached for real... sorry about this.
--
Henrique Holschuh
Aptitude 0.8.7: log report
Sun, Dec 3 2017 05:03:16 -0200
IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.
Will install 17 packages, and remove 0 packages.
13.3
35 matches
Mail list logo
