glibc 2.25 machine status?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

glibc 2.25 machine status?

Carlos O'Donell-6
The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).

Chris,

Will you have a chance to submit TILE-Gx and TILEPro build results for glibc 2.25[1]?

Samuel,

Will you have a chance to submit x86 Hurd build results for glibc 2.25[1]?

David,

Will you have a chance to submit SPARC 32/64-bit build results for glibc 2.25[1]?

H.J,

Will you have a chance to submit x32 build results for glibc 2.25[1]?

Mike,

Will you have a chance to submit Gentoo build results for glibc 2.25[1] for the various
machines that don't yet have build results? ;-)

--
Cheers,
Carlos.

[1] https://sourceware.org/glibc/wiki/Release/2.25
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Adhemerval Zanella-2


On 30/01/2017 22:18, Carlos O'Donell wrote:

> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).
>
> Chris,
>
> Will you have a chance to submit TILE-Gx and TILEPro build results for glibc 2.25[1]?
>
> Samuel,
>
> Will you have a chance to submit x86 Hurd build results for glibc 2.25[1]?
>
> David,
>
> Will you have a chance to submit SPARC 32/64-bit build results for glibc 2.25[1]?
>
> H.J,
>
> Will you have a chance to submit x32 build results for glibc 2.25[1]?
>
> Mike,
>
> Will you have a chance to submit Gentoo build results for glibc 2.25[1] for the various
> machines that don't yet have build results? ;-)
>

John Paul Adrian Glaubitz ([hidden email]) has kindle provided the check
results for on a SH machine.  I will update it.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

H.J. Lu-30
In reply to this post by Carlos O'Donell-6
On Mon, Jan 30, 2017 at 4:18 PM, Carlos O'Donell <[hidden email]> wrote:

> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).
>
> Chris,
>
> Will you have a chance to submit TILE-Gx and TILEPro build results for glibc 2.25[1]?
>
> Samuel,
>
> Will you have a chance to submit x86 Hurd build results for glibc 2.25[1]?
>
> David,
>
> Will you have a chance to submit SPARC 32/64-bit build results for glibc 2.25[1]?
>
> H.J,
>
> Will you have a chance to submit x32 build results for glibc 2.25[1]?

Done.   I only see

FAIL: elf/tst-leaks1-mem

https://sourceware.org/bugzilla/show_bug.cgi?id=14681

FAIL: nptl/tst-setuid2

> Mike,
>
> Will you have a chance to submit Gentoo build results for glibc 2.25[1] for the various
> machines that don't yet have build results? ;-)
>
> --
> Cheers,
> Carlos.
>
> [1] https://sourceware.org/glibc/wiki/Release/2.25



--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Chris Metcalf-2
In reply to this post by Carlos O'Donell-6
On 1/30/2017 7:18 PM, Carlos O'Donell wrote:
> Will you have a chance to submit TILE-Gx and TILEPro build results for glibc 2.25[1]?

I will post my current build results for TILE-Gx with gcc 4.8, but
omit the tst-setcontext2 bug, since it is fixed with a newer gcc.
I'll double-check with a full gcc 6.3 build and test shortly.

I have not yet had a chance to do a TILEPro cross-build, but I will
do so and update the results when I get a chance.  It may not be
by tomorrow though.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Joseph Myers
In reply to this post by Adhemerval Zanella-2
On Tue, 31 Jan 2017, Adhemerval Zanella wrote:

> John Paul Adrian Glaubitz ([hidden email]) has kindle provided the check
> results for on a SH machine.  I will update it.

There's something very odd about those results - they have

FAIL: elf/check-localplt
original exit status 1
Extra PLT reference: libc.so: _Unwind_Find_FDE
Extra PLT reference: libc.so: _exit
Extra PLT reference: libc.so: __errno_location

but those PLT references are listed in
sysdeps/unix/sysv/linux/sh/localplt.data, while there are several XPASSes
with no corresponding XFAIL in the checked-in glibc sources.  Are you sure
this is actually testing with sources from recent unmodified glibc master?

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Adhemerval Zanella-2


On 31/01/2017 15:51, Joseph Myers wrote:

> On Tue, 31 Jan 2017, Adhemerval Zanella wrote:
>
>> John Paul Adrian Glaubitz ([hidden email]) has kindle provided the check
>> results for on a SH machine.  I will update it.
>
> There's something very odd about those results - they have
>
> FAIL: elf/check-localplt
> original exit status 1
> Extra PLT reference: libc.so: _Unwind_Find_FDE
> Extra PLT reference: libc.so: _exit
> Extra PLT reference: libc.so: __errno_location
>
> but those PLT references are listed in
> sysdeps/unix/sysv/linux/sh/localplt.data, while there are several XPASSes
> with no corresponding XFAIL in the checked-in glibc sources.  Are you sure
> this is actually testing with sources from recent unmodified glibc master?
>

The information I could extract from log only refers to 2.24.9 and it is from
a debian build/check.  I can ask John how update is the package he used, but
it does seem he did not used a recent revision.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Florian Weimer-5
In reply to this post by Carlos O'Donell-6
On 01/31/2017 01:18 AM, Carlos O'Donell wrote:
> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).

I tried to run the x86_64 build & test suite under the Windows 10
subsystem.  The subsystem is not ready for that yet, and it does not
make sense to track test failures at this point.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Carlos O'Donell-6
On 02/01/2017 03:56 AM, Florian Weimer wrote:
> On 01/31/2017 01:18 AM, Carlos O'Donell wrote:
>> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).
>
> I tried to run the x86_64 build & test suite under the Windows 10
> subsystem.  The subsystem is not ready for that yet, and it does not
> make sense to track test failures at this point.

Please add your results to the wiki.

Having a record of an attempt from a senior community member is
as valuable as a record of success or failure.

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Siddhesh Poyarekar-8
In reply to this post by Carlos O'Donell-6
On Tuesday 31 January 2017 05:48 AM, Carlos O'Donell wrote:
> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).

Florian and I are still working on the fix to tunables environment
variables behavior.  It is a critical flaw that we need to fix before
the fix goes out, so the release is held up until then.

I understand we still haven't resolved the deadlock over bug 20019 and
21041.  Is there any conclusion in sight and if so, how long do you
think that would take?

Then there is 20915 which is also under discussion and is the last of
our blockers.

Lets plan to wrap all of those up before the end of the week.  I will
cut the branch and release on Sunday and y'all will have the master
branch open for 2.26 before Monday starts.

Sounds OK?

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Florian Weimer-5
On 02/01/2017 06:09 PM, Siddhesh Poyarekar wrote:
> On Tuesday 31 January 2017 05:48 AM, Carlos O'Donell wrote:
>> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).
>
> Florian and I are still working on the fix to tunables environment
> variables behavior.  It is a critical flaw that we need to fix before
> the fix goes out, so the release is held up until then.

As a fallback, we could simply strip GLIBC_TUNABLES for HAVE_TUNABLES as
well.  This would reduce most of the risk from this change.

Florian
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Siddhesh Poyarekar-8
On Wednesday 01 February 2017 11:15 PM, Florian Weimer wrote:
> As a fallback, we could simply strip GLIBC_TUNABLES for HAVE_TUNABLES as
> well.  This would reduce most of the risk from this change.

It needs to be correct because it breaks compatibility between
MALLOC_CHECK_ and glibc.malloc.check.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Adhemerval Zanella-2
In reply to this post by Carlos O'Donell-6


On 30/01/2017 22:18, Carlos O'Donell wrote:

> The glibc 2.25 release date is Feburary 1st 2017 (this Wednesday).
>
> Chris,
>
> Will you have a chance to submit TILE-Gx and TILEPro build results for glibc 2.25[1]?
>
> Samuel,
>
> Will you have a chance to submit x86 Hurd build results for glibc 2.25[1]?
>
> David,
>
> Will you have a chance to submit SPARC 32/64-bit build results for glibc 2.25[1]?
>

John Paul Adrian kindly gave me access to a Niagara T5 machine and I added results
for sparc32 and sparc64.

> H.J,
>
> Will you have a chance to submit x32 build results for glibc 2.25[1]?
>
> Mike,
>
> Will you have a chance to submit Gentoo build results for glibc 2.25[1] for the various
> machines that don't yet have build results? ;-)
>
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

David Miller-13
In reply to this post by Adhemerval Zanella-2

Carlos, I ran some 32-bit Sparc v9 tests, there are math test failures
which are easy to fix (all of the sparcv9 and VIS3 fmin/fmax assembler
routines do not generate exceptions properly).  The fix is simply to
remove them.

A more difficult case is the sparcv9 version of s_lrint.S which
sometimes erroneously generates inexact excepations.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Siddhesh Poyarekar-8
In reply to this post by Carlos O'Donell-6
Hi all,

So the summary for status is now as follows:

- There are failures on SPARC32 that need fixing

- I am not clear on the resolution status of pr#20915.  It appeared
  that there was consensus on reverting one of the hunks from commit
  17af5da9 but there seem to be differences in that

- I have posted a tunables test case fix that I'll commit soon if
  nobody objects

Pr 20915 is the only blocker so provided that it is resolved in time, I
intend to cut a release this Sunday.  If the blocker is not resolved in
time, the release will be on the day or one day after the blocker is
resolved, depending on how it aligns with my timezone and/or my sleep
pattern at that time.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Adhemerval Zanella-2


On 03/02/2017 09:08, Siddhesh Poyarekar wrote:
> Hi all,
>
> So the summary for status is now as follows:
>
> - There are failures on SPARC32 that need fixing

It is not only for sparc32, all sparc assembly implementation requires fixes
for sNaN/qNaN distinction. I took a quick look at this and:

  1. Removing sparc assembly implementation is the straightforward fix, as
     pointed out by David.

  2. sparc default implementation [1]] is slight slower for default finite number
     compared to C code.  The advantage is shows constant performance for all
     kind of inputs, while C implementation is showers for Inf/{q,s}NaNs.  However
     it will likely get slower with the sNaN/qNaN fix since it will most likely
     requires more instructions to fix it.

  3. sparc vis3 [2] is faster than C implementation for all inputs, however as for
     2. it might get slower with the proper fix.

One option could be removing [1] and check if fixing [2] yields any performance gain
compared to [1].  Otherwise removing both is the best option.

In any way, it is a nice fix to have, but it is not a release blocker imho.

[1] sysdeps/sparc/sparc64/fpu/s_f{max,min}.S and ./sysdeps/sparc/sparc32/sparcv9/fpu/s_f{max.min}.S
[2] sysdeps/sparc/sparc64/fpu/multiarch/s_f{max,min}-vis3.S and
    ./sysdeps/sparc/sparc32/sparcv9/fpu/multiarch/s_f{max.min}-vis3.S

>
> - I am not clear on the resolution status of pr#20915.  It appeared
>   that there was consensus on reverting one of the hunks from commit
>   17af5da9 but there seem to be differences in that
>
> - I have posted a tunables test case fix that I'll commit soon if
>   nobody objects
>
> Pr 20915 is the only blocker so provided that it is resolved in time, I
> intend to cut a release this Sunday.  If the blocker is not resolved in
> time, the release will be on the day or one day after the blocker is
> resolved, depending on how it aligns with my timezone and/or my sleep
> pattern at that time.
>
> Siddhesh
>
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Siddhesh Poyarekar-8
On Friday 03 February 2017 05:00 PM, Adhemerval Zanella wrote:
> One option could be removing [1] and check if fixing [2] yields any performance gain
> compared to [1].  Otherwise removing both is the best option.
>
> In any way, it is a nice fix to have, but it is not a release blocker imho.

Thanks for the detailed analysis.  Changing routines so close to the
release is a bit tricky IMO and we have in the past deferred it until
after the release.  I'd say lets do the same for this too unless not
fixing this has a significant and known impact on known applications or
workloads on sparc.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Carlos O'Donell-6
In reply to this post by David Miller-13
On 02/02/2017 08:21 PM, David Miller wrote:
>
> Carlos, I ran some 32-bit Sparc v9 tests, there are math test failures
> which are easy to fix (all of the sparcv9 and VIS3 fmin/fmax assembler
> routines do not generate exceptions properly).  The fix is simply to
> remove them.
>
> A more difficult case is the sparcv9 version of s_lrint.S which
> sometimes erroneously generates inexact excepations.
>

Thanks.

Siddhesh won't be cutting the branch until Sunday because of a few other
last minute blocker's that we're clearing off the decks.

Therefore if you want to commit the SPARC-only changes, please do so,
and post the test results to the wiki?

https://sourceware.org/glibc/wiki/Release/2.25

Anything in the wiki is better than nothing. Just saying what system
you used for testing and compiler+binutils+kernel combination is useful
information for others.

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Carlos O'Donell-6
In reply to this post by Siddhesh Poyarekar-8
On 02/03/2017 06:08 AM, Siddhesh Poyarekar wrote:
> Hi all,
>
> So the summary for status is now as follows:
>
> - There are failures on SPARC32 that need fixing

This should not block the release and I've told Dave Miller (in the
test status request thread) that he should just make whatever changes
he needs making since it's restricted to the SPARC32 backend. Anything
is better than broken.

> - I am not clear on the resolution status of pr#20915.  It appeared
>   that there was consensus on reverting one of the hunks from commit
>   17af5da9 but there seem to be differences in that

My only goal today is to try fix this with a minimum of change and
retest across all the affected arches. I have a bunch of boxes on loan
to use for that.

> - I have posted a tunables test case fix that I'll commit soon if
>   nobody objects

Your patches there look good to me.

> Pr 20915 is the only blocker so provided that it is resolved in time, I
> intend to cut a release this Sunday.  If the blocker is not resolved in
> time, the release will be on the day or one day after the blocker is
> resolved, depending on how it aligns with my timezone and/or my sleep
> pattern at that time.

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Carlos O'Donell-6
In reply to this post by Siddhesh Poyarekar-8
On 02/03/2017 06:36 AM, Siddhesh Poyarekar wrote:

> On Friday 03 February 2017 05:00 PM, Adhemerval Zanella wrote:
>> One option could be removing [1] and check if fixing [2] yields any performance gain
>> compared to [1].  Otherwise removing both is the best option.
>>
>> In any way, it is a nice fix to have, but it is not a release blocker imho.
>
> Thanks for the detailed analysis.  Changing routines so close to the
> release is a bit tricky IMO and we have in the past deferred it until
> after the release.  I'd say lets do the same for this too unless not
> fixing this has a significant and known impact on known applications or
> workloads on sparc.

I think Dave or the distributions should make that choice, but if it's really
broken then fixing it would be better than nothing.

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.25 machine status?

Siddhesh Poyarekar-8
On Friday 03 February 2017 06:41 PM, Carlos O'Donell wrote:
> I think Dave or the distributions should make that choice, but if it's really
> broken then fixing it would be better than nothing.

That is fair, I reckon machine maintainers have a final say on what goes
into their part of the code base anyway.  What I said is my
recommendation as release manager since changing whole subroutines
during freeze is not trivial.

Siddhesh
12