[I messed up the freebsd-emulation email address the first time I sent
this. I also forgot to indicate the qemu-user-static vintage relationship.]

I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port 
cross
builds in another message sequence. But it turns out that one thing I ran into
has hung-up every time, the same way, for amd64->armv7 cross builds:
multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate 
report
with some updated notes.

A little context: I had built from ports head -r484783 before under FreeBSD head
-r340287 (as I remember the version). Back then it did not have this problem 
that it
now has under FreeBSD head -r341836 . One ports-specific change was to force 
perl5.28
as the default instead of perl5.26 originally. In fact this is what drives what 
is
being rebuilt for my experiment that caught this. But I doubt the perl version 
is
important to the problem. The context has a Ryzen Threadripper 1950X and has 
been
tested both for FreeBSD under Hyper-V and for the same media native-booted. Both
hang-up at the same point as seen via ps or top. The native tools for 
cross-build
speedup were in use. Cross-builds targeting aarch64 did not get this problem but
targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
first
armv7 try.

ADDED: The qemu-user-static back with head -r340287 before installing the
updated ports would likely be different than the -r484783 vintage. So both
FreeBSD and qemu-user-static may have changed over the comparison.


The hang-up:

In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and 
timed
out. Looking during the wait in later tries shows something much like (from one 
of the
examples):

root       33719    0.0  0.0  12920  3528  0  I    11:40       0:00.03 | |      
     `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root       41551    0.0  0.0  12920  3520  0  I    11:43       0:00.00 | |      
       `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root       41552    0.0  0.0  10340  1744  0  IJ   11:43       0:00.01 | |      
         `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 
build
root       41566    0.0  0.0  10236  1796  0  IJ   11:43       0:00.00 | |      
           `-- /bin/sh -e -c (cd 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env 
QT_SELE
root       41567    0.0  0.0  89976 12896  0  IJ   11:43       0:00.07 | |      
             `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
root       41585    0.0  0.0 102848 25056  0  IJ   11:43       0:00.10 | |      
               |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g
root       41586    0.0  0.0 102852 25072  0  IJ   11:43       0:00.11 | |      
               `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g

or as top showed it:

41552 root          1  52    0    10M  1744K    0 wait    15   0:00   0.00% 
/usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
41566 root          1  52    0    10M  1796K    0 wait     1   0:00   0.00% 
/bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; 
if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
41567 root          2  52    0    88M    13M    0 select   4   0:00   0.00% 
/usr/local/bin/qemu-arm-static ninja -j28 -v all
41585 root          2  52    0   100M    24M    0 kqread   8   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
41586 root          2  52    0   100M    24M    0 kqread  22   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.

So: waiting in kqread trying to run cmake.

Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
resume the hung-up processes. Kills of the processes waiting on kqread stop
the build.

Given the prior ports have been built already, building just
multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.

Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to