Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Dec 2018 15:21:50 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        freebsd-emulation@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
Subject:   Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
Message-ID:  <5C3F09FE-EA50-452D-98EE-364B7BF3ECD0@yahoo.com>
In-Reply-To: <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com>
References:  <FF9B4284-4E6B-4D36-86A0-18861B527AC0@yahoo.com> <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[A native poudreire-devel based build of
multimedia/gstreamer1-qt@qt5 did not hang-up
and worked fine. Official package build history
also provides some evidence.]

On 2018-Dec-22, at 12:55, Mark Millard <marklmi@yahoo.com> wrote:

> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
>=20
> On 2018-Dec-22, at 00:10, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> [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.]
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful =
cross-builds
> based on qemu-user-static from ports head -484783 --all built under =
FreeBSD
> head -r340287 . So the use of the perl5.28 as the forced-default and =
the
> newer FreeBSD head version -r341836 as the context are the differences =
here.
>=20
>> The hang-up:
>>=20
>> 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):
>>=20
>> 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=3Dqt5 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
>>=20
>> or as top showed it:
>>=20
>> 41552 root          1  52    0    10M  1744K    0 wait    15   0:00   =
0.00% /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=3Dqt5 =
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=3Dqt5 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/.
>>=20
>> So: waiting in kqread trying to run cmake.
>>=20
>> 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.
>>=20
>> Given the prior ports have been built already, building just
>> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same =
point.
>>=20
>> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to =
be
>> solidly blocked in my environment.


I tried building multimedia/gstreamer1-qt@qt5 on a Orange Pi 2 2nd
Edition and the build did not hang-up. This was also based on FreeBSD
head -r341836 and ports head -r484783 .

This test was set up in part by copying over the
/usr/local/poudriere/data/packages/ material from what that did
cross build. So, for example, the cmake used should be a binary exact
match.

The FreeBSD head -r341836 was installed from the same buildworld
buildkernel tree that the cross-build's installworld was based on.

The problem is somehow specific to cross-builds (and so
qemu-user-static being involved).


Other evidence (official package build attempts):

I looked at beefy16.nyi.freebsd.org 's head-armv7-default and
beefy8.nyi.freebsd.org 's head-armv6-default histories and
the problem does not exist for the:

FreeBSD -r332419 ports -r467121

combination but exists for the later ones, starting with:

FreeBSD -r332632 ports -r467547

Interestingly qemu-sbruno (the master port for qemu-user-static)
was not updated in that ports range, being from -r463452 .

There was a cmake change at -r467437 but the more modern
native result suggests cmake is not currently contributing
(and, so, likely was not the issue back then).

That possibly leaves qemu-user-static for targeting armv7 (and v6)
misinterpreting something different from the different
FreeBSD versions. For example, there was a change to return
EAGAIN instead of EIO for certain conditions, between -r332419
and -r332632 : at -r332631 . (I do not know that it is
involved.)


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C3F09FE-EA50-452D-98EE-364B7BF3ECD0>