The following is from the same system but different boot media selected in
EDK2's UEFI/ACPI. A summary for a 16-core HoneyComb Cortex-A72 system is
UFS: 80sec+ ZFS: 10sec or so. I am limited to at most 16 cores for aarch64.
HoneyComb (16 cpu) UFS (so: NO_ZFS=yes) with USE_TMPFS="data" (main system
On a HoneyComb (16 cores) I did a bulk -a targetting armv7 that had
emulators/mame fail as unable to allocate during a link. Linking
by default use slightly more threads than the freebsd cpu count.
The HoneyComb had 64 GiByte of RAM and over 12 MiByte of
swap partitioning set up. The swap was n
I've been doing some testing of bulk -a builds on a HoneyComb
(16 Cortex-A72's). A first bulk -a got some timeouts and
such for which I edited, for example, MAX_EXECUTION_TIME_PACKAGE
in /usr/local/etc/poudriere.conf . I then started another
bulk -a for it to finish off the builds. No changes to
[00:00:45] [06] [00:00:18] Saving ports-mgmt/poudriere-devel |
poudriere-devel-3.3.99.20211015 wrkdir
[00:00:49] [06] [00:00:22] Saved ports-mgmt/poudriere-devel |
poudriere-devel-3.3.99.20211015 wrkdir to:
/usr/local/poudriere/data/wrkdirs/13_0R-CA72-default/default/poudriere-devel-3.3.99.202
On 2021-Oct-16, at 19:20, Mark Millard via freebsd-toolchain
wrote:
> [00:00:45] [06] [00:00:18] Saving ports-mgmt/poudriere-devel |
> poudriere-devel-3.3.99.20211015 wrkdir
> [00:00:49] [06] [00:00:22] Saved ports-mgmt/poudriere-devel |
> poudriere-devel-3.3.99.202110
On 2021-Oct-16, at 23:41, Mark Millard wrote:
On 2021-Oct-16, at 19:20, Mark Millard via freebsd-toolchain
wrote:
>
>
>> [00:00:45] [06] [00:00:18] Saving ports-mgmt/poudriere-devel |
>> poudriere-devel-3.3.99.20211015 wrkdir
>> [00:00:49] [06] [00:00:22] Saved po
On 2021-Oct-17, at 11:19, Mark Millard wrote:
> On 2021-Oct-16, at 23:41, Mark Millard wrote:
>
> On 2021-Oct-16, at 19:20, Mark Millard via freebsd-toolchain
> wrote:
>>
>>
>>> [00:00:45] [06] [00:00:18] Saving ports-mgmt/poudriere-devel |
>>&
On 2021-Nov-15, at 10:40, Dimitry Andric wrote:
> On 15 Nov 2021, at 19:14, Mark Millard via arm wrote:
>>
>> There error was:
>>
>> error: non-constant-expression cannot be narrowed from type 'long long' to
>> 'std::size_t' (aka 'unsi
>> gned int') in initializer list [-Wc++11-narrowing]
>>
On 2021-Nov-15, at 11:35, Mark Millard wrote:
> On 2021-Nov-15, at 10:40, Dimitry Andric wrote:
>
>> On 15 Nov 2021, at 19:14, Mark Millard via arm wrote:
>>>
>>> There error was:
>>>
>>> error: non-constant-expression cannot be narrowed from type 'long long' to
>>> 'std::size_t' (aka 'u
