Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 27 Jul 2024 00:14:31 UTC
On Jul 26, 2024, at 16:44, Warner Losh <imp@bsdimp.com> wrote:

> On Fri, Jul 26, 2024, 5:37 PM Mark Millard <marklmi@yahoo.com> wrote:
>> On Jul 26, 2024, at 07:56, Philip Paeps <philip@freebsd.org> wrote:
>> 
>> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> >> So, it looks like updating the kernel and world on ampere2 and
>> >> enabling builds of main-armv7-default should no longer have
>> >> main-armv7-default hang-up during graphviz installation (or
>> >> analogous contexts). Hopefully, that means that
>> >> main-armv7-default builds will then complete and be distributed.
>> > 
>> > I've set the stop-builds flag on the ampere machines.  I'll kick off a cluster build and upgrade them when they finish their current builds (or get stuck).
>> > 
>> > Thanks for chasing this down.
>> 
>> FYI: As stands, only main has the update. The MFC will not happen
>> for about a week. ampere1 and ampere3 should probably wait to
>> upate until after the MFC since they do not build main-armv7-* .
>> 
>> Note: The fix is a world change, not a kernel change. So it is
>> the jail's world that matters.
>> 
>> I'm not sure if any existing releng/13.*/ or releng/14.*/ will
>> get an update for this. stable/13/ and stable/14/ are likely to.
> 
> I wonder if a rebuilt system will make it through an armv7 bsd-user poudriere bulk....

I assume that this wording is about having amd64 with qemu attempting
bulk -a for building amv7 packages, not about having aarch64 (without
qemu) bulk -a with armv7 jails do so (which are now being done). Have
I got that right?

(It appears that main used to have some prior use of the __aeabi_* in
question before the failure point, thereby historically avoiding the
recursive lock use deadlock. 13 and 14 are still operational for
bulk -a on aarch64 for armv7 jails --but are subject to breakage,
just like main was.)

If spreading the package-building load around more to amd64 contexts
was a goal, and if amd64 with qemu worked well for aarch64, one could
imagine having some of the aarch64 package builds on amd64 but all
the armv7 ones on the ampere*'s. This may be more likely to work
better overall than amd64 with qemu ever handling a 32-bit context
well (armv7 here).


===
Mark Millard
marklmi at yahoo.com