[Bug 265241] Runaway builds on armv6, armv7 in port cad/iverilog
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 15 Jul 2022 20:02:44 UTC
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.