From nobody Fri Nov 07 16:49:05 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d34kG0zB9z6GC3V; Fri, 07 Nov 2025 16:48:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d34kF64hmz3m95; Fri, 07 Nov 2025 16:48:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A7Gn62f006305 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 7 Nov 2025 08:49:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A7Gn5TX006304; Fri, 7 Nov 2025 08:49:05 -0800 (PST) (envelope-from fbsd) Date: Fri, 7 Nov 2025 08:49:05 -0800 From: bob prohaska To: Paul Mather Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d34kF64hmz3m95 On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote: > On Nov 6, 2025, at 9:22 pm, bob prohaska wrote: > > > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: > >> On Nov 6, 2025, at 08:38, bob prohaska 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