Date: Fri, 28 Dec 2018 12:12:06 -0800 From: Mark Millard <marklmi@yahoo.com> To: mmel@freebsd.org Cc: freebsd-emulation@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org>, 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: <ABA957EA-B8EE-4B8C-9C2F-B745BA652BF6@yahoo.com> In-Reply-To: <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> References: <FF9B4284-4E6B-4D36-86A0-18861B527AC0@yahoo.com> <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <A6A58CE3-062B-4B79-A8C2-ADFDAA04C6AF@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Dec-28, at 05:13, Michal Meloun <melounmichal at gmail.com> =
wrote:
> Mark,
> this is known problem with qemu-user-static.
> Emulation of every single interruptible syscall is broken by design =
(it
> have signal related races). Theses races cannot be solved without =
major
> rewrite of syscall emulation code.
> Unfortunately, nobody actively works on this, I think.
>=20
Thanks for the note setting some expectations.
On the evidence that I have I expect that more is going on than that:
A) The hang-up always happens and always in the same place. So
it would appear that no race is involved.
B) (A) is true even for varying the number of builders in parallel
(so other builds also happening) and the number of jobs allowed per
builder. It also fails for only one builder allowed only one process.
(I get traces from that last kind of context.)
C) The problem started on the package-building servers for armv7
and armv6 without qemu-user-static having an update (FreeBSD and
cmake had updates, for example).
D) The problem is only observed for targeting armv7 and armv6 as
far as I can tell. I've never seen it for aarch64, neither my
own builds nor when I looked at the package-building server
history.
At least that is what got me started. (I've since learned that
qemu-user-static uses fork in place of a requested vfork.)
My ktrace/kdump experiment yesterday showed something odd for the
kevent that hangs in cmake:
93172 qemu-arm-static CALL =
kevent(0x3,0x7ffffffe7d40,0x2,0x7ffffffd7d40,0x400,0)
93172 qemu-arm-static STRU struct kevent[] =3D { { ident=3D6, =
filter=3DEVFILT_READ, flags=3D0x1<EV_ADD>, fflags=3D0, data=3D0, =
udata=3D0x0 }
{ ident=3D0x0, filter=3D<invalid=3D0>, flags=3D0, =
fflags=3D0x8, data=3D0x1ffff, udata=3D0x0 } }
Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the =
struct
kevent[]. The kevent use is from cmake.
So far I've not identified a signal being delivered at a time that would =
seem
to me to be likely to contribute. (But this is not familiar code so my =
judgment
is likely not the best.)
Note: I normally run FreeBSD using a non-debug kernel, even when using
head. (The kernel does have symbols.)
=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?ABA957EA-B8EE-4B8C-9C2F-B745BA652BF6>