Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld
- In reply to: Paul Mather : "Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 07 Nov 2025 16:49:05 UTC
On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote: > On Nov 6, 2025, at 9:22 pm, bob prohaska <fbsd@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 <fbsd@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