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
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm,gmane.os.freebsd.devel.ports,gmane.os.freebsd.current |
|---|---|
| Message-ID | <[email protected]> |
On Jul 26, 2024, at 16:44, Warner Losh <[email protected]> wrote: > On Fri, Jul 26, 2024, 5:37 PM Mark Millard <[email protected]> wrote: >> On Jul 26, 2024, at 07:56, Philip Paeps <[email protected]> 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