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 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