Re: -current on armv7 stuck with flashing disk light

On Jun 26, 2023, at 19:57, Mark Millard <marklmi@yahoo.com> 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
> 
> (No claim such is the only way to lose control.)

If I get a loss of control, then I can infer that it
was something other than the kernel stacks being
moved to the swap space, presuming no bug has been
created in the handling of the assigned values.

Without the assignments, there is not as solid of
evidence pointing an any specific direction. I
prefer to have the evidence.

> 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