This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Machine maintainers, please test your machines.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Chris Metcalf <cmetcalf at ezchip dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at suse dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, David Holsgrove <david dot holsgrove at xilinx dot com>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Sat, 24 Jan 2015 07:37:03 -0800
- Subject: Re: glibc 2.21 - Machine maintainers, please test your machines.
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com>
On Sat, Jan 24, 2015 at 7:14 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> On 1/23/2015 4:32 PM, Carlos O'Donell wrote:
>>
>> Dear Machine Maintainers,
>>
>> Please start testing your machines against glibc
>> master.
>>
>> Please update the glibc 2.21 release page with your
>> testing results:
>>
>> https://sourceware.org/glibc/wiki/Release/2.21
>>
>> If nobody objects I want to cut the release as soon
>> as we have results for all the machines.
>>
>> Cheers,
>> Carlos.
>
>
> tilegx64 is fine (modulo the one bug compiler bug that has been outstanding
> for multiple glibc releases now).
>
> tilegx32 has a bunch of new failures, all of which manifest as bus errors:
>
> FAIL: nptl/tst-sem14
> FAIL: nptl/tst-sem3
> FAIL: nptl/tst-sem6
> FAIL: nptl/tst-signal3
> FAIL: nptl/tst-tls2
> FAIL: nptl/tst-tls3
>
> I assume these are all from the new semaphore code but have not had an
> opportunity to look more closely. One thing that could cause this is if
> somehow we are trying to do atomic operations on 64-bit values that aren't
> aligned to an 8-byte boundary.
>
Can you verify if it is the case?
--
H.J.