Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 14 Nov 2025 21:57:44 UTC
On Nov 10, 2025, at 17:46, bob prohaska <fbsd@www.zefox.net> wrote:

> On Mon, Nov 10, 2025 at 07:02:35PM +0000, void wrote:
>> On Mon, Nov 10, 2025 at 07:39:51AM -0800, bob prohaska wrote:
>> 
>>> Did the machine hang entirely? If so, how did you recover control?
>> 
>> locked solid. rebooted.
>> 
>> The machine responded ok interactively until that point.
>> 
> Have you attempted a debugger escape on the serial console?
> Enter, tilda, control-B is the default on -current
> 
> If it works some extra information can be furnished to those
> trying to help. I'm not among them, but have been the beneficiary
> many times in the past.

[There is also the jemalloc assertion issue.]

This is just a note about how things go in
another context, with more cores, more RAM
and aarch64 handling armv7 via a chroot to
an armv7 world.

Context: Windows Dev Kit 2023, 8 cores,
32 GiBytes of RAM, USB3 media. main 16
via an official pkgbase distribution
installation. swap was configured but
went unused: SwapUsed==0 was always
observed. No /etc/src*.conf .

# cat /etc/make.conf 
WRKDIRPREFIX?=/wrkdirs

So . . .

A from-scratch armv7:

# env WITH_META_MODE make -j8 buildworld buildkernel

worked just fine, taking somewhat under 4 hours.
6298Mi MaxObs(Act+Wired+Laundry+SwapUsed), Inact
started large from prior activity and stayed large.
("MaxObs" is short for: Maximum Observed.)

So it does tend to suggest that memory pressure
handling contributes to at least making the
problems more likely to occur --and might even
be required.


Part of the reason this was tried is that jemalloc
is world code, not kernel code. Thus jemalloc
assertions need not require the armv7 kernel.


I can also test telling FreeBSD to use only, say,
2 GiBytes of RAM and pick the 3.5 GiByte SWAP space
that is available, so RAM+SWAP==5.5 GiBytes, still
using -j8 . /boot/loader.conf :

hw.physmem="2G"

It may be that I'd need closer to 3G to avoid
running out of RAM+SWAP.


===
Mark Millard
marklmi at yahoo.com