Date: Fri, 7 Nov 2025 09:02:43 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: <C468E73A-655A-448A-B9F8-BDB47BD34D6D@yahoo.com> In-Reply-To: <aQ4bbyc3Pc4yOWyO@www.zefox.net> References: <aQyrBArxXq-JSaqu@www.zefox.net> <475995705.6919.1762440301455@localhost> <aQzPBMjvuCoY-kY-@www.zefox.net> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <aQ1X7WDt3-qPy1Bx@www.zefox.net> <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.com> <aQ4bbyc3Pc4yOWyO@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On Nov 7, 2025, at 08:16, bob prohaska <fbsd@www.zefox.net> wrote: > On Thu, Nov 06, 2025 at 08:15:49PM -0800, Mark Millard wrote: >> >> The enter-tilda-control-B sequence is via the tty driver and >> kernel. It is not tied to a specific process. >> > > Would debugging via JTAG offer any better recourse to a > silent hang? I have no experience with JTAG or analogous. My logic analyzer background does not really apply. Even if I managed to replicate the behavior, I've not come up with any way of being able to gather useful evidence based on what you have reported. One avoid-the-problem technique is to build on a more capable system that supports armv7 chroot use --by mounting the drive and chrooting to it, doing the build and install in the chroot, and then exit, dismount, and move the media back to the RPI2. This does have the advantage that the live kernel is not being changed and the system processes are not being updated, so reboots during the install are not required: There are no runtime conflicts with the live system. But it also assumes that your context supports also having the disk media mounted on the more capable system for a while. === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C468E73A-655A-448A-B9F8-BDB47BD34D6D>