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

From: Ronald Klop <ronald-lists_at_klop.ws>
Date: Fri, 07 Nov 2025 17:19:02 UTC
Van: bob prohaska <fbsd@www.zefox.net>
Datum: 7 november 2025 17:48
Aan: Paul Mather <paul@gromit.dlib.vt.edu>
CC: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

> 
> 
> On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote:
> > On Nov 6, 2025, at 9:22pm, bob prohaska www.zefox.net> wrote:
> > 
> > > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote:
> > >> On Nov 6, 2025, at 08:38, bob prohaska www.zefox.net> wrote:
> > >> 
> > >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote:
> > >>>> Hi,
> > >>>> 
> > >>>> To me it sounds like your machine is overwhelmed by swapping.
> > >>>> 
> > >>>> Try -j1 buildworld.
> > > Maybe a -j1 buildworld could be at least somewhat informative.
> > > Lately none of my Pi2's has made it through buildworld 
> > > without hanging silently. If -j1 buildworld completes,
> > > that would be a significant change. The test will take a
> > > week, but the problem has been going on for a year.
> > 
> > 
> > This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards.
> 
> In the past FreeBSD was quite vocal about running out of memory/swap. It would issue warnings
> on the console that swap was low, slow to become available, or exhausted. In this case nothing
> of the sort is happening. The machine does bog down when swap usage exceeds about 500MB, but
> it doesn't stop or complain. The scheduler seems to figure out which theads are making progress
> and gives them higher priority. Eventually the backlog is worked through, swap use drops to
> 50 MB or less and CPU usage rises to 90+% per core. 
> 
> That's when the system is hanging and unresponsive to enter-tilda-control-B. If it's a 
> memory exhaustion issue it's happening invisibly and only later causing a stoppage.
> It's the invisibility of the problem which hints at a deeper flaw. I don't think it's
> possible to anticipate how much memory a program will eventually require, but it does
> seem possible to recognize when a resource limit is crossed, if that's the problem. 
> 
> I think a -j1 buildworld is likely worth a try, but if it succeeds I don't have
> any idea where it'll point a finger.
> 
> Thanks for writing!
> 
> bob prohaska
>  
> 
> 
> 
> 
> 
> 


If it fails without swapping you know you need to look somewhere else. 

Regards,
Ronald