Re: -current on armv7 stuck with flashing disk light
Date: Tue, 27 Jun 2023 02:57:05 UTC
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 (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? (You did not indicate how long you let it run with the status "possibly hung up".) > 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. === Mark Millard marklmi at yahoo.com