Re: -current on armv7 stuck with flashing disk light

On Jun 26, 2023, at 19:12, bob prohaska <[email protected]> wrote:

> A Pi2 freshly updated to 
> FreeBSD 14.0-CURRENT #41 main-c3e58ace31: Mon Jun 26 17:06:01 PDT 2023
>    [email protected]:/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
>    [email protected]:/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