Date: Tue, 27 Jun 2023 09:29:03 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: -current on armv7 stuck with flashing disk light Message-ID: <ZJsOTzp%2Bb7O2%2BbhQ@www.zefox.net> In-Reply-To: <A91FF89C-2BAA-4E93-96FA-C75C6FA4A0A0@yahoo.com> References: <ZJpFqAnnKPq/XmxJ@www.zefox.net> <A91FF89C-2BAA-4E93-96FA-C75C6FA4A0A0@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 26, 2023 at 07:57:05PM -0700, Mark Millard wrote: > On Jun 26, 2023, at 19:12, bob prohaska <fbsd@www.zefox.net> wrote: > > > A Pi2 freshly updated to > > FreeBSD 14.0-CURRENT #41 main-c3e58ace31: Mon Jun 26 17:06:01 PDT 2023 > > bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm > > got stuck with a flashing USB disk LED after starting a -j3 buildworld. > > No response to debugger escape, had to pull the plug. > > If I understand right, the LED flashing means the disk > had not stopped doing I/O: the system was still running, > doing disk activity. (But I do not have a description > of what your drive documentation says about how the > drive handles the LED and what various patterns/colors > may mean.) > > If the processes associated with processing input that > would identify the debugger escape had the kernel stacks > involved swapped out to swap space, I doubt that the > debugger escape would work until/unless the kernel > stacks are brought back into kernel RAM. > > Avoiding the specific way of losing control is why I > have in /etc/sysctl.conf : > > # > # Together this pair avoids swapping out the process kernel stacks. > # This avoids processes for interacting with the system from being > # hung-up by such. > vm.swap_enabled=0 > vm.swap_idle_enabled=0 > This combination was tried and didn't seem to have any consistent effect. It's commented out at the moment. > (No claim such is the only way to lose control.) > > You might be able to get a clue if their was disk I/O going > on based on modification times on files you know would have > been modified periodically for some time (minutes) before > you pulled the plug --but not modified on reboot and later > activity. May be a log file that would only be modified by > the build that you had been trying to do? > There are log files for build and disk activity (for a cold hang, no disk activity at all) at http://nemesis.zefox.com/~bob/fbsd/rpi2/20230623/ In this case the top window was via ssh. Lately I've taken to running top on the serial console in hopes that will help distinguish system hangs from USB hangs. > (You did not indicate how long you let it run with the > status "possibly hung up".) > IIRC it was about half an hour. It was already stuck, so I don't know the actual time > > Reboot with kernel.old, > > FreeBSD 14.0-CURRENT #40 main-c1cbabe8ae: Tue Jun 20 03:58:47 PDT 2023 > > bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm > > seems ok, I'll try to run buildworld with that. The kernel.old -j3 buildworld is still running, no complaints so far. If it succeeds I'll experiment with usbtop. Thanks for writing!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZJsOTzp%2Bb7O2%2BbhQ>