* [Buildroot] [autobuild.buildroot.net] Build results for 2018-08-11
@ 2018-08-12 6:00 Thomas Petazzoni
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-12 6:00 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2018-08-11
===============================
branch | OK | NOK | TIM | TOT |
2018.02.x | 19 | 1 | 1 | 21 |
2018.05.x | 17 | 0 | 0 | 17 |
master | 186 | 21 | 2 | 209 |
next | 38 | 5 | 0 | 43 |
Results for branch '2018.02.x'
==============================
Classification of failures by reason
------------------------------------
host-cryptsetup-2.0.0 | 1
host-libsodium | 1
Detail of failures
------------------
arm | host-cryptsetup-2.0.0 | NOK | http://autobuild.buildroot.net/results/fb7f3cc1f313e91fb0cf5820e715594b4e4f618e |
arm | host-libsodium | TIM | http://autobuild.buildroot.net/results/a05429a86fcce6ff63346a0775be1fbf8ef5c497 |
Results for branch 'master'
===========================
Classification of failures by reason
------------------------------------
boost-1.67.0 | 7
ncmpc-0.30 | 3
python-pyqt5-5.7 | 2
aircrack-ng-1.3 | 1
azure-iot-sdk-c | 1
host-cryptsetup-2.0.3 | 1
host-libselinux-2.7 | 1
linux-firmware | 1
micropython-v1.9.3 | 1
mjpegtools-2.1.0 | 1
owfs-3.2p1 | 1
shairport-sync-3.2.1 | 1
x265-2.8 | 1
zeromq-4.2.5 | 1
Detail of failures
------------------
powerpc | aircrack-ng-1.3 | NOK | http://autobuild.buildroot.net/results/87e82a5e8d0b1c1ff10ec3e59d25bcd56b329075 |
x86_64 | azure-iot-sdk-c | TIM | http://autobuild.buildroot.net/results/43b9bccacd88397d732fda16d998fa7dc001f900 |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/9dfffc1dcedefc3c4baee412ae36ae297f15cdba |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/ea533448148a2728a3faecb9c67fae849f17e62b |
xtensa | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/704d54409644e7e5ad0064029edc1b8020df1b80 |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/81ae35780e16c5c458e06228da180cf2d83eadf7 |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/7049a7ef91a7984848a2bcf67df792ed4dbe785f |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/4f3ff822f0f057bef22c1a59deae429d544be29c |
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/71006378450b5687240c455a72b5cc314704b776 |
arm | host-cryptsetup-2.0.3 | NOK | http://autobuild.buildroot.net/results/f46ef6123b5fa92753ff534b4ef7bea3f53ac388 |
x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
xtensa | linux-firmware | TIM | http://autobuild.buildroot.net/results/34b8bb8824d369e5b53e2a4effd1a8d18df07aee |
nios2 | micropython-v1.9.3 | NOK | http://autobuild.buildroot.net/results/276e07067ad630ce39b5e43d7e90cb8bd22a1925 |
powerpc | mjpegtools-2.1.0 | NOK | http://autobuild.buildroot.net/results/d63727755d671ef6ac484fe26a79793123976651 |
mips64el | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/d8a7339d8bdd5cdc6bd1716585d4bcf15a2e8015 |
mips | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/5af01895e0a58751ef342001bad5e17caf742b92 |
mips64el | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/b9857a5b8b4bb6f8a47e78cc14ee1f81852f6867 |
arm | owfs-3.2p1 | NOK | http://autobuild.buildroot.net/results/c30201b79b6e36df4bb14281036dcb23eda1edf6 |
arm | python-pyqt5-5.7 | NOK | http://autobuild.buildroot.net/results/ca3fe2e816ceeacb8218c0085bcb37413ef381c6 |
arm | python-pyqt5-5.7 | NOK | http://autobuild.buildroot.net/results/48b7ab85de68e1972853a10f5999f4240c5efd88 |
arm | shairport-sync-3.2.1 | NOK | http://autobuild.buildroot.net/results/60576363adfca404c3a7883d5d46e8a4a9ee8171 |
arm | x265-2.8 | NOK | http://autobuild.buildroot.net/results/da246c496854a3cec1cb4be3589264abd6f2c6de |
m68k | zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/295710ddc7ac11a88a2e8986ad35ac1803c7fe12 |
Results for branch 'next'
=========================
Classification of failures by reason
------------------------------------
boost-1.67.0 | 1
host-json-c-0.13.1 | 1
iperf3-3.6 | 1
openpowerlink-V2.7.0 | 1
owfs-3.2p1 | 1
Detail of failures
------------------
arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/8c7d8df2b957698ced006915a4765366260de1df |
arm | host-json-c-0.13.1 | NOK | http://autobuild.buildroot.net/results/c57c84fe5ad44101cf6ed7d13b73061126af248f |
arm | iperf3-3.6 | NOK | http://autobuild.buildroot.net/results/ba56d132c5994486066c304fa1f3872bb0f3ee32 |
i586 | openpowerlink-V2.7.0 | NOK | http://autobuild.buildroot.net/results/109e5696f929f3c1d3f9a8a6f86d1eeb776a3ab1 |
x86_64 | owfs-3.2p1 | NOK | http://autobuild.buildroot.net/results/6f36f249b8d33def49deeae010672b4cbd45f79b |
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-12 6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-08-11 Thomas Petazzoni
@ 2018-08-12 20:36 ` Thomas Petazzoni
2018-08-13 11:33 ` Romain Naour
` (3 more replies)
0 siblings, 4 replies; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-12 20:36 UTC (permalink / raw)
To: buildroot
Hello,
Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
below.
On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
> powerpc | aircrack-ng-1.3 | NOK | http://autobuild.buildroot.net/results/87e82a5e8d0b1c1ff10ec3e59d25bcd56b329075 |
Seems like some PowerPC Altivec code gets used even when Altivec is not
available, or something like that:
CC libaircrack_crypto_ppc_altivec_la-sha1-git.lo
memory.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
CC libaircrack_crypto_ppc_altivec_la-simd-intrinsics.lo
sha1-git.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
CC libaircrack_crypto_ppc_altivec_la-wpapsk.lo
simd-intrinsics.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
simd-intrinsics.c:147:18: error: unknown type name 'vtype'
simd-intrinsics.c: In function 'dispatch':
simd-intrinsics.c:671:3: warning: implicit declaration of function 'SIMDmd5body' [-Wimplicit-function-declaration]
simd-intrinsics.c:671:16: error: 'vtype' undeclared (first use in this function)
simd-intrinsics.c:671:16: note: each undeclared identifier is reported only once for each function it appears in
simd-intrinsics.c:671:23: error: expected expression before ')' token
simd-intrinsics.c: At top level:
simd-intrinsics.c:905:18: error: unknown type name 'vtype'
simd-intrinsics.c:1386:19: error: unknown type name 'vtype'
simd-intrinsics.c:1928:21: error: unknown type name 'vtype'
simd-intrinsics.c:2547:21: error: unknown type name 'vtype'
Anybody with some PowerPC understanding to look into this ? Matt perhaps ?
> x86_64 | azure-iot-sdk-c | TIM | http://autobuild.buildroot.net/results/43b9bccacd88397d732fda16d998fa7dc001f900 |
Hollis: your autobuilder times out when downloading this package, could
you have a look ? See
http://autobuild.buildroot.net/?reason=azure-iot-sdk-c%.
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/9dfffc1dcedefc3c4baee412ae36ae297f15cdba |
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/ea533448148a2728a3faecb9c67fae849f17e62b |
> xtensa | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/704d54409644e7e5ad0064029edc1b8020df1b80 |
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/81ae35780e16c5c458e06228da180cf2d83eadf7 |
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/7049a7ef91a7984848a2bcf67df792ed4dbe785f |
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/4f3ff822f0f057bef22c1a59deae429d544be29c |
> arm | boost-1.67.0 | NOK | http://autobuild.buildroot.net/results/71006378450b5687240c455a72b5cc314704b776 |
Again this libboost_atomic issue.
> arm | host-cryptsetup-2.0.3 | NOK | http://autobuild.buildroot.net/results/f46ef6123b5fa92753ff534b4ef7bea3f53ac388 |
lib/luks2/luks2.h:86: error: redefinition of typedef 'json_object'
/scratch1/hblancha/build/buildroot-autobuild/instance-0/output/host/include/json-c/json_object.h:160: note: previous declaration of 'json_object' was here
Hollis, this is happening only on your autobuilder, could you have a
look: http://autobuild.buildroot.net/?reason=host-cryptsetup%.
> x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
Same.
> xtensa | linux-firmware | TIM | http://autobuild.buildroot.net/results/34b8bb8824d369e5b53e2a4effd1a8d18df07aee |
Hollis, once again your autobuilder timing out when downloading stuff:
http://autobuild.buildroot.net/?reason=linux-firmware%.
> nios2 | micropython-v1.9.3 | NOK | http://autobuild.buildroot.net/results/276e07067ad630ce39b5e43d7e90cb8bd22a1925 |
cc1: warnings being treated as errors
../py/objdict.c: In function 'dict_view_print':
../py/objdict.c:458: error: dereferencing pointer 'o' does break strict-aliasing rules
../py/objdict.c:457: error: dereferencing pointer 'o' does break strict-aliasing rules
../py/objdict.c:456: error: dereferencing pointer 'o' does break strict-aliasing rules
../py/objdict.c:455: error: dereferencing pointer 'o' does break strict-aliasing rules
../py/objdict.c:454: note: initialized from here
make[1]: *** [build/py/objdict.o] Error 1
Hollis, this also only happens on your autobuilder:
http://autobuild.buildroot.net/?reason=micropython%.
Do you have a Docker container with the RHEL6.5 so that other people
can reproduce those issues ?
> powerpc | mjpegtools-2.1.0 | NOK | http://autobuild.buildroot.net/results/d63727755d671ef6ac484fe26a79793123976651 |
iquant_intra.c: In function 'iquant_intra_m1_altivec':
iquant_intra.c:122:10: internal compiler error: Segmentation fault
vsrc = vec_ld(offset, (signed short*)src);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Someone needs to dig into gcc bug reports, test with a more recent gcc,
etc. Romain, this is usually your stuff :-)
> mips64el | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/d8a7339d8bdd5cdc6bd1716585d4bcf15a2e8015 |
> mips | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/5af01895e0a58751ef342001bad5e17caf742b92 |
> mips64el | ncmpc-0.30 | NOK | http://autobuild.buildroot.net/results/b9857a5b8b4bb6f8a47e78cc14ee1f81852f6867 |
Fixed by
https://git.buildroot.org/buildroot/commit/?id=21f0507cc193469b8ba7fccc3fc07a2bbd12784b.
> arm | owfs-3.2p1 | NOK | http://autobuild.buildroot.net/results/c30201b79b6e36df4bb14281036dcb23eda1edf6 |
make[4]: Entering directory `/scratch1/hblancha/build/buildroot-autobuild/instance-0/output/build/owfs-3.2p1/src/man/man1'
/usr/bin/soelim -r -I ./.. owcapi.man > owcapi.1
/usr/bin/soelim: invalid option -- 'r'
usage: /usr/bin/soelim [ -vC ] [ -I file ] [ files ]
make[4]: *** [owcapi.1] Error 1
Hollis, this is again something that happens only on your build
machine: http://autobuild.buildroot.net/?reason=owfs%.
> arm | python-pyqt5-5.7 | NOK | http://autobuild.buildroot.net/results/ca3fe2e816ceeacb8218c0085bcb37413ef381c6 |
> arm | python-pyqt5-5.7 | NOK | http://autobuild.buildroot.net/results/48b7ab85de68e1972853a10f5999f4240c5efd88 |
Seems like
https://src.fedoraproject.org/rpms/python-qt5/c/47fb7fdc5d16582772f9c3fc8a6a674a41a7f605?branch=master
would fix it.
> arm | shairport-sync-3.2.1 | NOK | http://autobuild.buildroot.net/results/60576363adfca404c3a7883d5d46e8a4a9ee8171 |
checking for soxr_create in -lsoxr... no
configure: error: soxr support requested but libsoxr not found!
make[1]: *** [/home/peko/autobuild/instance-0/output/build/shairport-sync-3.2.1/.stamp_configured] Error 1
J?rg, this is your package, could you have a look ?
From a quick look at http://autobuild.buildroot.net/?reason=shairport%,
it seems to be happening since July 2.
> arm | x265-2.8 | NOK | http://autobuild.buildroot.net/results/da246c496854a3cec1cb4be3589264abd6f2c6de |
Scanning dependencies of target x265-shared
[ 97%] Linking CXX shared library libx265.so
ipfilter8.S.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make[4]: *** [libx265.so.160] Error 1
make[3]: *** [CMakeFiles/x265-shared.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs....
Bernd, this happened twice in recent times:
http://autobuild.buildroot.net/?reason=x265%. A parallel build issue
perhaps ?
> m68k | zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/295710ddc7ac11a88a2e8986ad35ac1803c7fe12 |
src/dish.cpp: In constructor 'zmq::dish_t::dish_t(zmq::ctx_t*, uint32_t, int)':
src/dish.cpp:49:1: internal compiler error: in connect_traces, at
dwarf2cfi.c:2752.
Another nice compiler failure. Romain ? :-)
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2018-08-13 11:33 ` Romain Naour
2018-08-13 14:15 ` Matthew Weber
` (2 subsequent siblings)
3 siblings, 0 replies; 26+ messages in thread
From: Romain Naour @ 2018-08-13 11:33 UTC (permalink / raw)
To: buildroot
Le 12/08/2018 ? 22:36, Thomas Petazzoni a ?crit?:
> Hello,
>
> Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
> below.
>
> On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
>
[snip]
>> powerpc | mjpegtools-2.1.0 | NOK | http://autobuild.buildroot.net/results/d63727755d671ef6ac484fe26a79793123976651 |
>
> iquant_intra.c: In function 'iquant_intra_m1_altivec':
> iquant_intra.c:122:10: internal compiler error: Segmentation fault
> vsrc = vec_ld(offset, (signed short*)src);
> ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Someone needs to dig into gcc bug reports, test with a more recent gcc,
> etc. Romain, this is usually your stuff :-)
>
>> m68k | zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/295710ddc7ac11a88a2e8986ad35ac1803c7fe12 |
>
> src/dish.cpp: In constructor 'zmq::dish_t::dish_t(zmq::ctx_t*, uint32_t, int)':
> src/dish.cpp:49:1: internal compiler error: in connect_traces, at
> dwarf2cfi.c:2752.
>
> Another nice compiler failure. Romain ? :-)
I'll take a look but I don't have much time this month, I'm on holidays :)
Best regards,
Romain
>
> Thomas
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
2018-08-13 11:33 ` Romain Naour
@ 2018-08-13 14:15 ` Matthew Weber
2018-08-13 22:43 ` Arnout Vandecappelle
2018-08-13 14:36 ` Matthew Weber
2018-08-13 18:18 ` [Buildroot] autobuilder flock hangs Hollis Blanchard
3 siblings, 1 reply; 26+ messages in thread
From: Matthew Weber @ 2018-08-13 14:15 UTC (permalink / raw)
To: buildroot
Thomas,
On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
> below.
>
> On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
>
> > powerpc | aircrack-ng-1.3 | NOK | http://autobuild.buildroot.net/results/87e82a5e8d0b1c1ff10ec3e59d25bcd56b329075 |
>
> Seems like some PowerPC Altivec code gets used even when Altivec is not
> available, or something like that:
>
> CC libaircrack_crypto_ppc_altivec_la-sha1-git.lo
> memory.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> CC libaircrack_crypto_ppc_altivec_la-simd-intrinsics.lo
> sha1-git.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> CC libaircrack_crypto_ppc_altivec_la-wpapsk.lo
> simd-intrinsics.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> simd-intrinsics.c:147:18: error: unknown type name 'vtype'
> simd-intrinsics.c: In function 'dispatch':
> simd-intrinsics.c:671:3: warning: implicit declaration of function 'SIMDmd5body' [-Wimplicit-function-declaration]
> simd-intrinsics.c:671:16: error: 'vtype' undeclared (first use in this function)
> simd-intrinsics.c:671:16: note: each undeclared identifier is reported only once for each function it appears in
> simd-intrinsics.c:671:23: error: expected expression before ')' token
> simd-intrinsics.c: At top level:
> simd-intrinsics.c:905:18: error: unknown type name 'vtype'
> simd-intrinsics.c:1386:19: error: unknown type name 'vtype'
> simd-intrinsics.c:1928:21: error: unknown type name 'vtype'
> simd-intrinsics.c:2547:21: error: unknown type name 'vtype'
>
> Anybody with some PowerPC understanding to look into this ? Matt perhaps ?
Looks like there is no support for non-altivec ppc in this code. Is
there a way I can do a conditional dependency in kconfig?
Something like
depends on BR2_POWERPC_CPU_HAS_ALTIVEC if BR2_powerpc || BR2_powerpc64
|| BR2_powerpc64le
Matt
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
2018-08-13 11:33 ` Romain Naour
2018-08-13 14:15 ` Matthew Weber
@ 2018-08-13 14:36 ` Matthew Weber
2018-08-13 15:30 ` Matthew Weber
2018-08-13 18:18 ` [Buildroot] autobuilder flock hangs Hollis Blanchard
3 siblings, 1 reply; 26+ messages in thread
From: Matthew Weber @ 2018-08-13 14:36 UTC (permalink / raw)
To: buildroot
Hollis / Thomas,
On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
> below.
>
> On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
>
[snip]
> Hollis, this is happening only on your autobuilder, could you have a
> look: http://autobuild.buildroot.net/?reason=host-cryptsetup%.
>
> > x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
>
Require host gcc at least 4.7
http://patchwork.ozlabs.org/patch/957001/
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-13 14:36 ` Matthew Weber
@ 2018-08-13 15:30 ` Matthew Weber
2018-08-13 18:10 ` [Buildroot] host-libselinux atomics with GCC 4.4 Hollis Blanchard
0 siblings, 1 reply; 26+ messages in thread
From: Matthew Weber @ 2018-08-13 15:30 UTC (permalink / raw)
To: buildroot
All,
On Mon, Aug 13, 2018 at 9:36 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> Hollis / Thomas,
> On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
> > below.
> >
> > On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
> >
> [snip]
> > Hollis, this is happening only on your autobuilder, could you have a
> > look: http://autobuild.buildroot.net/?reason=host-cryptsetup%.
> >
> > > x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
> >
>
> Require host gcc at least 4.7
> http://patchwork.ozlabs.org/patch/957001/
v2. http://patchwork.ozlabs.org/project/buildroot/list/?series=60561
I've also opened a upstream ticket
https://github.com/SELinuxProject/selinux/issues/97. We'll see if I
can get traction there and maybe that determines kconfig vs patch?
Matt
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] host-libselinux atomics with GCC 4.4
2018-08-13 15:30 ` Matthew Weber
@ 2018-08-13 18:10 ` Hollis Blanchard
2018-08-13 18:25 ` Matthew Weber
0 siblings, 1 reply; 26+ messages in thread
From: Hollis Blanchard @ 2018-08-13 18:10 UTC (permalink / raw)
To: buildroot
On 08/13/2018 08:30 AM, Matthew Weber wrote:
> All,
> On Mon, Aug 13, 2018 at 9:36 AM Matthew Weber
> <matthew.weber@rockwellcollins.com> wrote:
>> Hollis / Thomas,
>> On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
>> <thomas.petazzoni@bootlin.com> wrote:
>>>> x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
>> Require host gcc at least 4.7
>> http://patchwork.ozlabs.org/patch/957001/
> v2. http://patchwork.ozlabs.org/project/buildroot/list/?series=60561
>
> I've also opened a upstream ticket
> https://github.com/SELinuxProject/selinux/issues/97. We'll see if I
> can get traction there and maybe that determines kconfig vs patch?
Thanks for opening that upstream issue.
Due to the surprisingly quick response from the maintainers, it looks
like we already have an answer: the patch is OK, so we don't need the
Kconfig changes. (A more aggressive patch is almost certainly OK too,
but I doubt anybody wants to fuss about it.)
Hollis Blanchard
Mentor Graphics Emulation Division
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] autobuilder flock hangs
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2018-08-13 14:36 ` Matthew Weber
@ 2018-08-13 18:18 ` Hollis Blanchard
2018-08-13 21:18 ` Thomas Petazzoni
2018-08-16 9:10 ` Thomas Petazzoni
3 siblings, 2 replies; 26+ messages in thread
From: Hollis Blanchard @ 2018-08-13 18:18 UTC (permalink / raw)
To: buildroot
On 08/12/2018 01:36 PM, Thomas Petazzoni wrote:
>
>> x86_64 | azure-iot-sdk-c | TIM | http://autobuild.buildroot.net/results/43b9bccacd88397d732fda16d998fa7dc001f900 |
> Hollis: your autobuilder times out when downloading this package, could
> you have a look ? See
> http://autobuild.buildroot.net/?reason=azure-iot-sdk-c%.
>> xtensa | linux-firmware | TIM | http://autobuild.buildroot.net/results/34b8bb8824d369e5b53e2a4effd1a8d18df07aee |
> Hollis, once again your autobuilder timing out when downloading stuff:
> http://autobuild.buildroot.net/?reason=linux-firmware%.
flock was hanging. I don't know why; have you experienced anything like
that?
I deleted the directories and subsequent manual dl-wrapper invocations
succeeded, so I restarted the builder.
Hollis Blanchard
Mentor Graphics Emulation Division
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] host-libselinux atomics with GCC 4.4
2018-08-13 18:10 ` [Buildroot] host-libselinux atomics with GCC 4.4 Hollis Blanchard
@ 2018-08-13 18:25 ` Matthew Weber
2018-08-13 19:43 ` Hollis Blanchard
0 siblings, 1 reply; 26+ messages in thread
From: Matthew Weber @ 2018-08-13 18:25 UTC (permalink / raw)
To: buildroot
Hollis,
On Mon, Aug 13, 2018 at 1:10 PM Hollis Blanchard
<hollis_blanchard@mentor.com> wrote:
>
> On 08/13/2018 08:30 AM, Matthew Weber wrote:
> > All,
> > On Mon, Aug 13, 2018 at 9:36 AM Matthew Weber
> > <matthew.weber@rockwellcollins.com> wrote:
> >> Hollis / Thomas,
> >> On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
> >> <thomas.petazzoni@bootlin.com> wrote:
> >>>> x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
> >> Require host gcc at least 4.7
> >> http://patchwork.ozlabs.org/patch/957001/
> > v2. http://patchwork.ozlabs.org/project/buildroot/list/?series=60561
> >
> > I've also opened a upstream ticket
> > https://github.com/SELinuxProject/selinux/issues/97. We'll see if I
> > can get traction there and maybe that determines kconfig vs patch?
> Thanks for opening that upstream issue.
>
> Due to the surprisingly quick response from the maintainers, it looks
> like we already have an answer: the patch is OK, so we don't need the
> Kconfig changes. (A more aggressive patch is almost certainly OK too,
> but I doubt anybody wants to fuss about it.)
>
Did you want to tie-off with upstream and then submit the patch here?
Matt
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] host-libselinux atomics with GCC 4.4
2018-08-13 18:25 ` Matthew Weber
@ 2018-08-13 19:43 ` Hollis Blanchard
2018-08-16 9:43 ` Thomas Petazzoni
0 siblings, 1 reply; 26+ messages in thread
From: Hollis Blanchard @ 2018-08-13 19:43 UTC (permalink / raw)
To: buildroot
On 08/13/2018 11:25 AM, Matthew Weber wrote:
> Hollis,
> On Mon, Aug 13, 2018 at 1:10 PM Hollis Blanchard
> <hollis_blanchard@mentor.com> wrote:
>> On 08/13/2018 08:30 AM, Matthew Weber wrote:
>>> All,
>>> On Mon, Aug 13, 2018 at 9:36 AM Matthew Weber
>>> <matthew.weber@rockwellcollins.com> wrote:
>>>> Hollis / Thomas,
>>>> On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
>>>> <thomas.petazzoni@bootlin.com> wrote:
>>>>>> x86_64 | host-libselinux-2.7 | NOK | http://autobuild.buildroot.net/results/e48c974980b8228302a76ac5b6afad14e7ce81c1 |
>>>> Require host gcc at least 4.7
>>>> http://patchwork.ozlabs.org/patch/957001/
>>> v2. http://patchwork.ozlabs.org/project/buildroot/list/?series=60561
>>>
>>> I've also opened a upstream ticket
>>> https://github.com/SELinuxProject/selinux/issues/97. We'll see if I
>>> can get traction there and maybe that determines kconfig vs patch?
>> Thanks for opening that upstream issue.
>>
>> Due to the surprisingly quick response from the maintainers, it looks
>> like we already have an answer: the patch is OK, so we don't need the
>> Kconfig changes. (A more aggressive patch is almost certainly OK too,
>> but I doubt anybody wants to fuss about it.)
> Did you want to tie-off with upstream and then submit the patch here?
"Want to": no, but I submitted the patch anyways. ;-)
Hollis Blanchard
Mentor Graphics Emulation Division
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] autobuilder flock hangs
2018-08-13 18:18 ` [Buildroot] autobuilder flock hangs Hollis Blanchard
@ 2018-08-13 21:18 ` Thomas Petazzoni
2018-08-13 21:28 ` Yann E. MORIN
2018-08-16 9:10 ` Thomas Petazzoni
1 sibling, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-13 21:18 UTC (permalink / raw)
To: buildroot
Hello,
+Yann in Cc.
On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
> >> x86_64 | azure-iot-sdk-c | TIM | http://autobuild.buildroot.net/results/43b9bccacd88397d732fda16d998fa7dc001f900 |
> > Hollis: your autobuilder times out when downloading this package, could
> > you have a look ? See
> > http://autobuild.buildroot.net/?reason=azure-iot-sdk-c%.
>
>
> >> xtensa | linux-firmware | TIM | http://autobuild.buildroot.net/results/34b8bb8824d369e5b53e2a4effd1a8d18df07aee |
> > Hollis, once again your autobuilder timing out when downloading stuff:
> > http://autobuild.buildroot.net/?reason=linux-firmware%.
> flock was hanging. I don't know why; have you experienced anything like
> that?
Not that I remember. Yann ?
> I deleted the directories and subsequent manual dl-wrapper invocations
> succeeded, so I restarted the builder.
Hm, OK. Let's see what happens in the next days, but this feels a bit
scary. Could you keep monitoring
http://autobuild.buildroot.net/?status=TIMEOUT and see if other
timeouts pop up on your autobuilder ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] autobuilder flock hangs
2018-08-13 21:18 ` Thomas Petazzoni
@ 2018-08-13 21:28 ` Yann E. MORIN
0 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2018-08-13 21:28 UTC (permalink / raw)
To: buildroot
Thomas, Hollis, All,
On 2018-08-13 23:18 +0200, Thomas Petazzoni spake thusly:
> Hello,
>
> +Yann in Cc.
>
> On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
>
> > >> x86_64 | azure-iot-sdk-c | TIM | http://autobuild.buildroot.net/results/43b9bccacd88397d732fda16d998fa7dc001f900 |
> > > Hollis: your autobuilder times out when downloading this package, could
> > > you have a look ? See
> > > http://autobuild.buildroot.net/?reason=azure-iot-sdk-c%.
> >
> >
> > >> xtensa | linux-firmware | TIM | http://autobuild.buildroot.net/results/34b8bb8824d369e5b53e2a4effd1a8d18df07aee |
> > > Hollis, once again your autobuilder timing out when downloading stuff:
> > > http://autobuild.buildroot.net/?reason=linux-firmware%.
> > flock was hanging. I don't know why; have you experienced anything like
> > that?
> Not that I remember. Yann ?
Nope.
flock(1) is just a utility wrapper around flock(2), which is itself a
syscall to the kernel. The kernel frees a lock as soon as the process
that aqcquired it closes the filedescriptor(s) used to acquire that
lock, which also automatically occurs when the process dies (naturally
or forcibly).
So, barring a kernel bug, I'd say something else also had a lock...
You can get the list of process haviong locks with the lslocks command.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-13 14:15 ` Matthew Weber
@ 2018-08-13 22:43 ` Arnout Vandecappelle
2018-08-14 2:21 ` Matthew Weber
0 siblings, 1 reply; 26+ messages in thread
From: Arnout Vandecappelle @ 2018-08-13 22:43 UTC (permalink / raw)
To: buildroot
On 13-08-18 16:15, Matthew Weber wrote:
> Thomas,
> On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> Hello,
>>
>> Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
>> below.
>>
>> On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
>>
>>> powerpc | aircrack-ng-1.3 | NOK | http://autobuild.buildroot.net/results/87e82a5e8d0b1c1ff10ec3e59d25bcd56b329075 |
>>
>> Seems like some PowerPC Altivec code gets used even when Altivec is not
>> available, or something like that:
>>
>> CC libaircrack_crypto_ppc_altivec_la-sha1-git.lo
>> memory.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
>> CC libaircrack_crypto_ppc_altivec_la-simd-intrinsics.lo
>> sha1-git.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
>> CC libaircrack_crypto_ppc_altivec_la-wpapsk.lo
>> simd-intrinsics.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
>> simd-intrinsics.c:147:18: error: unknown type name 'vtype'
>> simd-intrinsics.c: In function 'dispatch':
>> simd-intrinsics.c:671:3: warning: implicit declaration of function 'SIMDmd5body' [-Wimplicit-function-declaration]
>> simd-intrinsics.c:671:16: error: 'vtype' undeclared (first use in this function)
>> simd-intrinsics.c:671:16: note: each undeclared identifier is reported only once for each function it appears in
>> simd-intrinsics.c:671:23: error: expected expression before ')' token
>> simd-intrinsics.c: At top level:
>> simd-intrinsics.c:905:18: error: unknown type name 'vtype'
>> simd-intrinsics.c:1386:19: error: unknown type name 'vtype'
>> simd-intrinsics.c:1928:21: error: unknown type name 'vtype'
>> simd-intrinsics.c:2547:21: error: unknown type name 'vtype'
>>
>> Anybody with some PowerPC understanding to look into this ? Matt perhaps ?
>
> Looks like there is no support for non-altivec ppc in this code. Is
> there a way I can do a conditional dependency in kconfig?
>
> Something like
> depends on BR2_POWERPC_CPU_HAS_ALTIVEC if BR2_powerpc || BR2_powerpc64
> || BR2_powerpc64le
I think that works, if not you can convert it into
depends on BR2_POWERPC_CPU_HAS_ALTIVEC || \
!(BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le)
("if" is the same as "or not". Think about it.)
Regards,
Arnout
>
> Matt
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Analysis of build results for 2018-08-11
2018-08-13 22:43 ` Arnout Vandecappelle
@ 2018-08-14 2:21 ` Matthew Weber
0 siblings, 0 replies; 26+ messages in thread
From: Matthew Weber @ 2018-08-14 2:21 UTC (permalink / raw)
To: buildroot
All,
On Mon, Aug 13, 2018 at 5:43 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 13-08-18 16:15, Matthew Weber wrote:
> > Thomas,
> > On Sun, Aug 12, 2018 at 3:36 PM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> >>
> >> Hello,
> >>
> >> Matt, Hollis, Romain, J?rg, Bernd, there are some questions for you
> >> below.
> >>
> >> On Sun, 12 Aug 2018 08:00:15 +0200 (CEST), Thomas Petazzoni wrote:
> >>
> >>> powerpc | aircrack-ng-1.3 | NOK | http://autobuild.buildroot.net/results/87e82a5e8d0b1c1ff10ec3e59d25bcd56b329075 |
> >>
> >> Seems like some PowerPC Altivec code gets used even when Altivec is not
> >> available, or something like that:
> >>
> >> CC libaircrack_crypto_ppc_altivec_la-sha1-git.lo
> >> memory.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> >> CC libaircrack_crypto_ppc_altivec_la-simd-intrinsics.lo
> >> sha1-git.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> >> CC libaircrack_crypto_ppc_altivec_la-wpapsk.lo
> >> simd-intrinsics.c:1:0: warning: -mvsx requires hardware floating point [enabled by default]
> >> simd-intrinsics.c:147:18: error: unknown type name 'vtype'
> >> simd-intrinsics.c: In function 'dispatch':
> >> simd-intrinsics.c:671:3: warning: implicit declaration of function 'SIMDmd5body' [-Wimplicit-function-declaration]
> >> simd-intrinsics.c:671:16: error: 'vtype' undeclared (first use in this function)
> >> simd-intrinsics.c:671:16: note: each undeclared identifier is reported only once for each function it appears in
> >> simd-intrinsics.c:671:23: error: expected expression before ')' token
> >> simd-intrinsics.c: At top level:
> >> simd-intrinsics.c:905:18: error: unknown type name 'vtype'
> >> simd-intrinsics.c:1386:19: error: unknown type name 'vtype'
> >> simd-intrinsics.c:1928:21: error: unknown type name 'vtype'
> >> simd-intrinsics.c:2547:21: error: unknown type name 'vtype'
> >>
https://patchwork.ozlabs.org/patch/957337/
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] autobuilder flock hangs
2018-08-13 18:18 ` [Buildroot] autobuilder flock hangs Hollis Blanchard
2018-08-13 21:18 ` Thomas Petazzoni
@ 2018-08-16 9:10 ` Thomas Petazzoni
2018-08-24 7:02 ` [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs] Yann E. MORIN
1 sibling, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-16 9:10 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
> flock was hanging. I don't know why; have you experienced anything like
> that?
>
> I deleted the directories and subsequent manual dl-wrapper invocations
> succeeded, so I restarted the builder.
This happened again:
http://autobuild.buildroot.net/results/ddb/ddbc96b24017f2a2b06c6091dea3e19520bf2dd1/
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] host-libselinux atomics with GCC 4.4
2018-08-13 19:43 ` Hollis Blanchard
@ 2018-08-16 9:43 ` Thomas Petazzoni
0 siblings, 0 replies; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-16 9:43 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 13 Aug 2018 12:43:10 -0700, Hollis Blanchard wrote:
> >> Due to the surprisingly quick response from the maintainers, it looks
> >> like we already have an answer: the patch is OK, so we don't need the
> >> Kconfig changes. (A more aggressive patch is almost certainly OK too,
> >> but I doubt anybody wants to fuss about it.)
> > Did you want to tie-off with upstream and then submit the patch here?
> "Want to": no, but I submitted the patch anyways. ;-)
I took your libselinux patch, added it in package/libselinux/, and
applied:
https://git.buildroot.org/buildroot/commit/?id=6288409642d8368104f916bd264d2cb042942dfa
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-16 9:10 ` Thomas Petazzoni
@ 2018-08-24 7:02 ` Yann E. MORIN
2018-08-24 23:45 ` Hollis Blanchard
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Yann E. MORIN @ 2018-08-24 7:02 UTC (permalink / raw)
To: buildroot
Hollis, Julien, Matthew, Thomas, All,
On 2018-08-16 11:10 +0200, Thomas Petazzoni spake thusly:
> On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
> > flock was hanging. I don't know why; have you experienced anything like
> > that?
> This happened again:
> http://autobuild.buildroot.net/results/ddb/ddbc96b24017f2a2b06c6091dea3e19520bf2dd1/
I think we now can see a pattern in those timeouts from Hollis'
autobuilder: they only ever happen on a slect group of 4 packages that
are downloaded with git:
- linux-firmware (kernel.org)
- f2fs-tools (kernel.org)
- azure-iot-sdk-c (github.com)
- uhttpd (openwrt.org)
Could you try to download them manually from your autobuilder, and see
if that works or not, please?
Is there something on your network that systematically makes those
packages fail to download? Do you have firewalling restrictions or
extreme traffic shapping?
Note that the size of those packages ranges from ~150KiB for uhttpd,
which is not really big, to 195MiB for linux-firmware, which is rather
large but nothing compared to a kernel tree. So we can probably rule
out the actual size of the package...
Now, I also had a look at all the timeouts, and I also noticed a single
other pattern. Julien's and Matthew's autobuilder would always choke on
host-libsodium, and it happens only on those two autobuilders:
http://autobuild.buildroot.org/?reason=host-libsodium
All failing at the same point:
checking whether segmentation violations can be caught when using the C compiler...
Matthew, Julien, could you have a look at what is causing those on your
autobuilders?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-24 7:02 ` [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs] Yann E. MORIN
@ 2018-08-24 23:45 ` Hollis Blanchard
2018-08-25 13:05 ` Yann E. MORIN
2018-08-24 23:54 ` Matthew Weber
2018-08-27 16:31 ` Julien Boibessot
2 siblings, 1 reply; 26+ messages in thread
From: Hollis Blanchard @ 2018-08-24 23:45 UTC (permalink / raw)
To: buildroot
On 08/24/2018 12:02 AM, Yann E. MORIN wrote:
> Hollis, Julien, Matthew, Thomas, All,
>
> On 2018-08-16 11:10 +0200, Thomas Petazzoni spake thusly:
>> On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
>>> flock was hanging. I don't know why; have you experienced anything like
>>> that?
>> This happened again:
>> http://autobuild.buildroot.net/results/ddb/ddbc96b24017f2a2b06c6091dea3e19520bf2dd1/
> I think we now can see a pattern in those timeouts from Hollis'
> autobuilder: they only ever happen on a slect group of 4 packages that
> are downloaded with git:
> - linux-firmware (kernel.org)
> - f2fs-tools (kernel.org)
> - azure-iot-sdk-c (github.com)
> - uhttpd (openwrt.org)
>
> Could you try to download them manually from your autobuilder, and see
> if that works or not, please?
>
> Is there something on your network that systematically makes those
> packages fail to download? Do you have firewalling restrictions or
> extreme traffic shapping?
azure-iot-sdk-c takes just 26 seconds to clone by hand.
I stopped the autobuilder, then ran a br-reproduce job that took all
day, which ended up at the "rauc" error that y'all just fixed. So... I
guess it didn't time out.
While the autobuilder was still running, I did see some strange
processes though:
init(1)-+
|-flock(3937)
|-flock(4688)
|-flock(4774)
|-flock(9733)
|-flock(10710)
|-flock(10885)---bash(10886)---bash(10889)---git(10898)---git-remote-http(10899)---git(10902)
|-flock(11942)
|-flock(13311)---bash(13312)---bash(13315)---git(13324)---git-remote-http(13325)---git(13328)
|-flock(13681)
|-flock(13915)
|-flock(14113)
|-flock(17018)
|-flock(18869)
|-flock(19152)---bash(19153)---bash(19156)---git(19227)---git-submodule(19228)---git-submodule(19329)---git-submodule(20382+
|-flock(19819)
|-flock(21944)
|-flock(22375)
|-flock(25233)
|-flock(25622)
|-flock(26921)
|-flock(28424)---bash(28425)---bash(28428)---git(28437)---git-remote-http(28438)---git(28441)
|-flock(30945)
|-flock(31269)
|-flock(31271)
|-flock(32627)
|-sh(20815)---bash(20816)---bash(20818)---git(20823)---git-remote-http(20824)---git(20826)
They disappeared when I killed the autobuilder (which is surprising --
seems like they're children of init, so why did they die?).
I suspect a) something goes wrong with the buildroot job, b) it's killed
in a way that leaves a dangling flock, c) future buildroot jobs run
headlong into the lingering flock and triggers a timeout.
--
Hollis Blanchard
Mentor Graphics Emulation Division
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-24 7:02 ` [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs] Yann E. MORIN
2018-08-24 23:45 ` Hollis Blanchard
@ 2018-08-24 23:54 ` Matthew Weber
2018-08-25 13:31 ` Yann E. MORIN
2018-08-27 16:31 ` Julien Boibessot
2 siblings, 1 reply; 26+ messages in thread
From: Matthew Weber @ 2018-08-24 23:54 UTC (permalink / raw)
To: buildroot
Yann,
On Fri, Aug 24, 2018 at 2:02 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Hollis, Julien, Matthew, Thomas, All,
>
> On 2018-08-16 11:10 +0200, Thomas Petazzoni spake thusly:
[snip]
> Now, I also had a look at all the timeouts, and I also noticed a single
> other pattern. Julien's and Matthew's autobuilder would always choke on
> host-libsodium, and it happens only on those two autobuilders:
>
> http://autobuild.buildroot.org/?reason=host-libsodium
>
> All failing at the same point:
>
> checking whether segmentation violations can be caught when using the C compiler...
>
Tried a few things...
1) Setup this config and did a make host-libsodium. No hang.
2) Took the test code from that configure test and could execute it without hang
3) Doing a full build now and we'll see if there is a sequencing/file
configuration driving this.
Any other ideas?
Matt
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-24 23:45 ` Hollis Blanchard
@ 2018-08-25 13:05 ` Yann E. MORIN
2018-09-27 17:18 ` Hollis Blanchard
0 siblings, 1 reply; 26+ messages in thread
From: Yann E. MORIN @ 2018-08-25 13:05 UTC (permalink / raw)
To: buildroot
Hollis, Thomas, All,
On 2018-08-24 16:45 -0700, Hollis Blanchard spake thusly:
> On 08/24/2018 12:02 AM, Yann E. MORIN wrote:
> >Hollis, Julien, Matthew, Thomas, All,
> >
> >On 2018-08-16 11:10 +0200, Thomas Petazzoni spake thusly:
> >>On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
> >>>flock was hanging. I don't know why; have you experienced anything like
> >>>that?
> >>This happened again:
> >> http://autobuild.buildroot.net/results/ddb/ddbc96b24017f2a2b06c6091dea3e19520bf2dd1/
> >I think we now can see a pattern in those timeouts from Hollis'
> >autobuilder: they only ever happen on a slect group of 4 packages that
> >are downloaded with git:
> > - linux-firmware (kernel.org)
> > - f2fs-tools (kernel.org)
> > - azure-iot-sdk-c (github.com)
> > - uhttpd (openwrt.org)
> >
> >Could you try to download them manually from your autobuilder, and see
> >if that works or not, please?
> >
> >Is there something on your network that systematically makes those
> >packages fail to download? Do you have firewalling restrictions or
> >extreme traffic shapping?
>
> azure-iot-sdk-c takes just 26 seconds to clone by hand.
OK.
> I stopped the autobuilder, then ran a br-reproduce job that took all day,
> which ended up at the "rauc" error that y'all just fixed. So... I guess it
> didn't time out.
Dang, I hate it when a failure is not reproducible... Heisenbugs are the
worst...
> While the autobuilder was still running, I did see some strange processes
> though:
>
> init(1)-+
> |-flock(3937)
> |-flock(4688)
> |-flock(4774)
> |-flock(9733)
> |-flock(10710)
> |-flock(10885)---bash(10886)---bash(10889)---git(10898)---git-remote-http(10899)---git(10902)
> |-flock(11942)
> |-flock(13311)---bash(13312)---bash(13315)---git(13324)---git-remote-http(13325)---git(13328)
> |-flock(13681)
> |-flock(13915)
> |-flock(14113)
> |-flock(17018)
> |-flock(18869)
> |-flock(19152)---bash(19153)---bash(19156)---git(19227)---git-submodule(19228)---git-submodule(19329)---git-submodule(20382+
> |-flock(19819)
> |-flock(21944)
> |-flock(22375)
> |-flock(25233)
> |-flock(25622)
> |-flock(26921)
> |-flock(28424)---bash(28425)---bash(28428)---git(28437)---git-remote-http(28438)---git(28441)
> |-flock(30945)
> |-flock(31269)
> |-flock(31271)
> |-flock(32627)
> |-sh(20815)---bash(20816)---bash(20818)---git(20823)---git-remote-http(20824)---git(20826)
>
> They disappeared when I killed the autobuilder (which is surprising -- seems
> like they're children of init, so why did they die?).
Indeed, that is really weird. :-/
> I suspect a) something goes wrong with the buildroot job, b) it's killed in
> a way that leaves a dangling flock, c) future buildroot jobs run headlong
> into the lingering flock and triggers a timeout.
So I had a look at the autobuilder code, and we kill the build process
with SIGKILL (-9)., so it has no chance of propagating it down to its
children.
I wonder if, should we were to use SIGTERM instead, there would be an
improvement. Could you try to leave your autobuilder running with this
patch, please?
diff --git a/scripts/autobuild-run b/scripts/autobuild-run
index 3d2e99a..ba86d3d 100755
--- a/scripts/autobuild-run
+++ b/scripts/autobuild-run
@@ -390,7 +390,7 @@ def stop_on_build_hang(monitor_thread_hung_build_flag,
if sub_proc.poll() is None:
monitor_thread_hung_build_flag.set() # Used by do_build() to determine build hang
log_write(log, "INFO: build hung")
- sub_proc.kill()
+ sub_proc.terminate()
break
monitor_thread_stop_flag.wait(30)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-24 23:54 ` Matthew Weber
@ 2018-08-25 13:31 ` Yann E. MORIN
2018-08-25 13:58 ` Romain Naour
2018-08-26 13:00 ` Matthew Weber
0 siblings, 2 replies; 26+ messages in thread
From: Yann E. MORIN @ 2018-08-25 13:31 UTC (permalink / raw)
To: buildroot
Matthew, Julien, All,
On 2018-08-24 18:54 -0500, Matthew Weber spake thusly:
> On Fri, Aug 24, 2018 at 2:02 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Now, I also had a look at all the timeouts, and I also noticed a single
> > other pattern. Julien's and Matthew's autobuilder would always choke on
> > host-libsodium, and it happens only on those two autobuilders:
> > http://autobuild.buildroot.org/?reason=host-libsodium
> > All failing at the same point:
> > checking whether segmentation violations can be caught when using the C compiler...
>
> Tried a few things...
> 1) Setup this config and did a make host-libsodium. No hang.
> 2) Took the test code from that configure test and could execute it without hang
> 3) Doing a full build now and we'll see if there is a sequencing/file
> configuration driving this.
>
> Any other ideas?
I found the commit that added this check:
https://github.com/jedisct1/libsodium/commit/c3045e2cb02dc1dae29cdb0dafd6cdb6469b8de8
So, does your host compiler runs asan by default? If so, do you have
ASAN_OPTIONS set in your environment?
(just throwing random guesses at it to see if any sticks...)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-25 13:31 ` Yann E. MORIN
@ 2018-08-25 13:58 ` Romain Naour
2018-08-26 13:00 ` Matthew Weber
1 sibling, 0 replies; 26+ messages in thread
From: Romain Naour @ 2018-08-25 13:58 UTC (permalink / raw)
To: buildroot
Le 25/08/2018 ? 15:31, Yann E. MORIN a ?crit?:
> Matthew, Julien, All,
>
> On 2018-08-24 18:54 -0500, Matthew Weber spake thusly:
>> On Fri, Aug 24, 2018 at 2:02 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>>> Now, I also had a look at all the timeouts, and I also noticed a single
>>> other pattern. Julien's and Matthew's autobuilder would always choke on
>>> host-libsodium, and it happens only on those two autobuilders:
>>> http://autobuild.buildroot.org/?reason=host-libsodium
>>> All failing at the same point:
>>> checking whether segmentation violations can be caught when using the C compiler...
>>
>> Tried a few things...
>> 1) Setup this config and did a make host-libsodium. No hang.
>> 2) Took the test code from that configure test and could execute it without hang
>> 3) Doing a full build now and we'll see if there is a sequencing/file
>> configuration driving this.
>>
>> Any other ideas?
>
> I found the commit that added this check:
> https://github.com/jedisct1/libsodium/commit/c3045e2cb02dc1dae29cdb0dafd6cdb6469b8de8
>
> So, does your host compiler runs asan by default? If so, do you have
> ASAN_OPTIONS set in your environment?
>
> (just throwing random guesses at it to see if any sticks...)
Last time we had autobuilders timeout was due to "futex(wait) system call", see
[1]. I'm not sure it's related but it was another mysterious unreproducible
(locally) bug.
Best regards,
Romain
[1]
https://git.buildroot.net/buildroot/commit/?id=0e162b932d67668a4f075da803efb62b01ec917d
>
> Regards,
> Yann E. MORIN.
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-25 13:31 ` Yann E. MORIN
2018-08-25 13:58 ` Romain Naour
@ 2018-08-26 13:00 ` Matthew Weber
1 sibling, 0 replies; 26+ messages in thread
From: Matthew Weber @ 2018-08-26 13:00 UTC (permalink / raw)
To: buildroot
Yann,
On Sat, Aug 25, 2018 at 8:31 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Matthew, Julien, All,
>
> On 2018-08-24 18:54 -0500, Matthew Weber spake thusly:
> > On Fri, Aug 24, 2018 at 2:02 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > > Now, I also had a look at all the timeouts, and I also noticed a single
> > > other pattern. Julien's and Matthew's autobuilder would always choke on
> > > host-libsodium, and it happens only on those two autobuilders:
> > > http://autobuild.buildroot.org/?reason=host-libsodium
> > > All failing at the same point:
> > > checking whether segmentation violations can be caught when using the C compiler...
> >
> > Tried a few things...
> > 1) Setup this config and did a make host-libsodium. No hang.
> > 2) Took the test code from that configure test and could execute it without hang
> > 3) Doing a full build now and we'll see if there is a sequencing/file
> > configuration driving this.
> >
> > Any other ideas?
>
> I found the commit that added this check:
> https://github.com/jedisct1/libsodium/commit/c3045e2cb02dc1dae29cdb0dafd6cdb6469b8de8
>
> So, does your host compiler runs asan by default? If so, do you have
> ASAN_OPTIONS set in your environment?
>
br-reproduce'd build doesn't fail or take a long time on
host-libsodium (below). I also checked my env, no define and I don't
have asan on this machine. Only difference now would be executing it
under the python autobuilder env. I'll see if I have autobuilder logs
from these failures (maybe I should add some logging, the signal test
maybe messes with the cmd shell?)
2659 1535170855:start:extract : host-libsodium
2660 1535170855:end :extract : host-libsodium
2661 1535170855:start:patch : host-libsodium
2662 1535170855:end :patch : host-libsodium
2663 1535170856:start:configure : host-libsodium
2664 1535170866:end :configure : host-libsodium
2665 1535170866:start:build : host-libsodium
2666 1535170871:end :build : host-libsodium
2667 1535170871:start:install-host : host-libsodium
2668 1535170872:end :install-host : host-libsodium
Matt
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-24 7:02 ` [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs] Yann E. MORIN
2018-08-24 23:45 ` Hollis Blanchard
2018-08-24 23:54 ` Matthew Weber
@ 2018-08-27 16:31 ` Julien Boibessot
2018-08-28 9:03 ` Thomas Petazzoni
2 siblings, 1 reply; 26+ messages in thread
From: Julien Boibessot @ 2018-08-27 16:31 UTC (permalink / raw)
To: buildroot
Hello all,
Yann,
thanks for investigating autobuilder issues.
On 24/08/2018 09:02, Yann E. MORIN wrote:
> Hollis, Julien, Matthew, Thomas, All,
>
> On 2018-08-16 11:10 +0200, Thomas Petazzoni spake thusly:
>> On Mon, 13 Aug 2018 11:18:10 -0700, Hollis Blanchard wrote:
>>> flock was hanging. I don't know why; have you experienced anything like
>>> that?
>> This happened again:
>> http://autobuild.buildroot.net/results/ddb/ddbc96b24017f2a2b06c6091dea3e19520bf2dd1/
> I think we now can see a pattern in those timeouts from Hollis'
> autobuilder: they only ever happen on a slect group of 4 packages that
> are downloaded with git:
> - linux-firmware (kernel.org)
> - f2fs-tools (kernel.org)
> - azure-iot-sdk-c (github.com)
> - uhttpd (openwrt.org)
>
> Could you try to download them manually from your autobuilder, and see
> if that works or not, please?
>
> Is there something on your network that systematically makes those
> packages fail to download? Do you have firewalling restrictions or
> extreme traffic shapping?
>
> Note that the size of those packages ranges from ~150KiB for uhttpd,
> which is not really big, to 195MiB for linux-firmware, which is rather
> large but nothing compared to a kernel tree. So we can probably rule
> out the actual size of the package...
>
>
> Now, I also had a look at all the timeouts, and I also noticed a single
> other pattern. Julien's and Matthew's autobuilder would always choke on
> host-libsodium, and it happens only on those two autobuilders:
>
> http://autobuild.buildroot.org/?reason=host-libsodium
>
> All failing at the same point:
>
> checking whether segmentation violations can be caught when using the C compiler...
>
> Matthew, Julien, could you have a look at what is causing those on your
> autobuilders?
I already signaled this problem on BR IRC chan. ;-)
When occurring, my autobuilder is stuck with a "conftest" process
consuming 100% of the CPU, indefinitely.
When building host-libsodium alone, all is fine.
When it fails with 100% CPU usage I can only kill the process and don't
see what is happening. I would say this problem is quite recent (3
months ?).
What can I do to look further ?
Best regards,
Julien
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-27 16:31 ` Julien Boibessot
@ 2018-08-28 9:03 ` Thomas Petazzoni
0 siblings, 0 replies; 26+ messages in thread
From: Thomas Petazzoni @ 2018-08-28 9:03 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 27 Aug 2018 18:31:53 +0200, Julien Boibessot wrote:
> > Matthew, Julien, could you have a look at what is causing those on your
> > autobuilders?
>
> I already signaled this problem on BR IRC chan. ;-)
> When occurring, my autobuilder is stuck with a "conftest" process
> consuming 100% of the CPU, indefinitely.
>
> When building host-libsodium alone, all is fine.
>
> When it fails with 100% CPU usage I can only kill the process and don't
> see what is happening. I would say this problem is quite recent (3
> months ?).
>
> What can I do to look further ?
conftest is the typical name of the programs built and run
by ./configure scripts to check/detect whatever they are told to check.
It would be useful to see the contents of the config.log file of
host-libsodium when the problem occurs, to see which particular test is
failing.
Also, is it something you can reproduce with br-reproduce-build
(https://git.buildroot.net/buildroot-test/plain/utils/br-reproduce-build),
using the hash of a build that timed out for you ? Maybe building
host-libsodium alone doesn't exhibit the problem, and it only appears
when a certain set of dependencies has been built prior to
host-libsodium.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs]
2018-08-25 13:05 ` Yann E. MORIN
@ 2018-09-27 17:18 ` Hollis Blanchard
0 siblings, 0 replies; 26+ messages in thread
From: Hollis Blanchard @ 2018-09-27 17:18 UTC (permalink / raw)
To: buildroot
On 08/25/2018 06:05 AM, Yann E. MORIN wrote:
> On 2018-08-24 16:45 -0700, Hollis Blanchard spake thusly:
>> I suspect a) something goes wrong with the buildroot job, b) it's killed in
>> a way that leaves a dangling flock, c) future buildroot jobs run headlong
>> into the lingering flock and triggers a timeout.
> So I had a look at the autobuilder code, and we kill the build process
> with SIGKILL (-9)., so it has no chance of propagating it down to its
> children.
>
> I wonder if, should we were to use SIGTERM instead, there would be an
> improvement. Could you try to leave your autobuilder running with this
> patch, please?
>
> diff --git a/scripts/autobuild-run b/scripts/autobuild-run
> index 3d2e99a..ba86d3d 100755
> --- a/scripts/autobuild-run
> +++ b/scripts/autobuild-run
> @@ -390,7 +390,7 @@ def stop_on_build_hang(monitor_thread_hung_build_flag,
> if sub_proc.poll() is None:
> monitor_thread_hung_build_flag.set() # Used by do_build() to determine build hang
> log_write(log, "INFO: build hung")
> - sub_proc.kill()
> + sub_proc.terminate()
> break
> monitor_thread_stop_flag.wait(30)
By the way, I tried this, came back weeks later, and found my
autobuilder hung like so:
[Fri, 07 Sep 2018 18:40:22] INFO: generate the configuration
KCONFIG_SEED=0xEB4D3CE
[Fri, 07 Sep 2018 18:40:40] INFO: build started
[Fri, 07 Sep 2018 22:39:10] INFO: build hung
output/logfile says:
>>> solarus v1.5.3 Building
<snip>
[ 88%] Building CXX object
CMakeFiles/solarus.dir/src/third_party/snes_spc/SNES_SPC_state.cpp.o
[ 88%] Building CXX object
CMakeFiles/solarus.dir/src/third_party/snes_spc/spc.cpp.o
[ 89%] Building CXX object
CMakeFiles/solarus.dir/src/third_party/snes_spc/SPC_DSP.cpp.o
[ 89%] Building CXX object
CMakeFiles/solarus.dir/src/third_party/snes_spc/SPC_Filter.cpp.o
[ 90%] Linking CXX shared library libsolarus.so
So it seems like solarus exceeded the build timeout (simple host
performance issue?), and .terminate() was not enough. However, I bet
.kill() would have left those subprocesses we saw earlier. (Also, in
hindsight, I suspect they were all flocks for the same directory or two,
so they all disappeared when the lock owner died.)
I have not tried your other patch series that changes download timeouts,
but I don't think it would have affected the particular case above,
since it's not stuck downloading.
Hollis Blanchard
Mentor Graphics Emulation Division
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180927/444ee999/attachment.html>
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2018-09-27 17:18 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-12 6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-08-11 Thomas Petazzoni
2018-08-12 20:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
2018-08-13 11:33 ` Romain Naour
2018-08-13 14:15 ` Matthew Weber
2018-08-13 22:43 ` Arnout Vandecappelle
2018-08-14 2:21 ` Matthew Weber
2018-08-13 14:36 ` Matthew Weber
2018-08-13 15:30 ` Matthew Weber
2018-08-13 18:10 ` [Buildroot] host-libselinux atomics with GCC 4.4 Hollis Blanchard
2018-08-13 18:25 ` Matthew Weber
2018-08-13 19:43 ` Hollis Blanchard
2018-08-16 9:43 ` Thomas Petazzoni
2018-08-13 18:18 ` [Buildroot] autobuilder flock hangs Hollis Blanchard
2018-08-13 21:18 ` Thomas Petazzoni
2018-08-13 21:28 ` Yann E. MORIN
2018-08-16 9:10 ` Thomas Petazzoni
2018-08-24 7:02 ` [Buildroot] Autobnuilders timeouts [was: Re: autobuilder flock hangs] Yann E. MORIN
2018-08-24 23:45 ` Hollis Blanchard
2018-08-25 13:05 ` Yann E. MORIN
2018-09-27 17:18 ` Hollis Blanchard
2018-08-24 23:54 ` Matthew Weber
2018-08-25 13:31 ` Yann E. MORIN
2018-08-25 13:58 ` Romain Naour
2018-08-26 13:00 ` Matthew Weber
2018-08-27 16:31 ` Julien Boibessot
2018-08-28 9:03 ` Thomas Petazzoni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.