[Bug 265241] Runaway builds on armv6, armv7 in port cad/iverilog

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265241

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #4 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Yuri Victorovich from comment #0)

> Log: /home/yuri/.cache/fallout/main-armv7-default/cad/iverilog/2022-07-15T19:02:59.log

As far as I can tell, this is a private path in your personal context
and does not give anyone else access to the log file in question.

Can you provide public log file access?

Is this a qemu based build environment? An aarch64 that is able to run
aarch32/armv7 code? Native armv7?

So far as I know, qemu has never gotten past the issue of having
various forms of hangups caused by qemu itself, although it has
been improving on the issue as I understand. ld's threading used
to be an example failure context that would show up, for example.

FreeBSD's build servers use qemu for armv7 builds.

If the context is qemu based, it is appropriate to have someone
check on a hardware environment in order to isolate qemu vs. other
cause. If it works on hardware, it likely is a qemu problem.

There is also the issue of the scaling of the various poudriere
timeouts in environments with different performance. Looking at
a recent FreeBSD build server log targeting armv7, I see after
an ld command:

=>> Killing runaway build after 21600 seconds with no output
=>> Cleaning up wrkdir
===>  Cleaning for iverilog-11.0
Killed
build of cad/iverilog | iverilog-11.0 ended at Sun Jul 10 04:22:58 UTC 2022
build time: 06:36:20
!!! build failure encountered !!!

Poudriere expects builds to have periodic status output, but
some ports do not have status output during some time consuming
activities.

Unlike the "/nxb-bin/usr/bin/cc"s in the log, The ld just is using:
"ld" --and so looks to be via qemu emulation, not special native
cross-tools (that are used to make things take much less time
than qemu based execution would).

For the FreeBSD build server, I'd guess a qemu related process hangup
from the threading activity --but I do not really know.

-- 
You are receiving this mail because:
You are the assignee for the bug.