Re: Armv7 unresponsive with flashing disk light

On Apr 25, 2025, at 17:54, bob prohaska <[email protected]> wrote:

> On Fri, Apr 25, 2025 at 05:02:36PM -0700, Mark Millard wrote:
>> 
>> 
>> On Apr 25, 2025, at 16:12, Robert Clausecker <[email protected]> wrote:
>> 
>>> Am Fri, Apr 25, 2025 at 02:46:58PM -0700 schrieb bob prohaska:
>>>> A Pi2 running -current armv7 got stuck again during buildworld.
>>>> No debugger escape was possible, despite repeated tries. Power
>>>> cycle was followed by a normal boot.
>>>> 
>>>> This time, the usb hard disk activity LED was pulsing steadily,
>>>> roughly 3-5 Hz. That's new. Formerly all stoppages had no disk
>>>> activity indications.
>>> 
>>> That could be the kernel dumping itself.  Did it eventually stop?
>> 
>> Per that note: you (Bob) may want to let the light blink
>> until its stops (or it has been a very long time) if such
>> happens again in the future. Then you might have a crash
>> dump to get information from once you do boot again.
> 
> It never crossed my mind that the disk activity could be
> a crash dump in progress. Dammit! Lost my chance. The
> two Pi2s running armv7 -current have been locking up 
> during buildworld for a year and I've never found
> a crash dump, nor been able to get at the debugger. 
> This was the first time I've seen _any_ change in behavior.
> 
> How long should a crash dump take? Both machines have
> dumpdev="AUTO"
> in /etc/rc.conf
> and swap partitions larger than RAM.

In the likes of:

# sysctl debug kern.coredump | grep dump
debug.minidump: 1
debug.dump_modinfo:  debug.elf32_legacy_coredump: 0
debug.elf64_legacy_coredump: 0
debug.ddb.textdump.do_version: 1
debug.ddb.textdump.do_panic: 1
debug.ddb.textdump.do_msgbuf: 1
debug.ddb.textdump.do_ddb: 1
debug.ddb.textdump.do_config: 1
debug.ddb.textdump.pending: 0
kern.coredump: 1

What shows up for "debug.minidump: " and
"kern.coredump: "?

Media type for partition/slice with the swap
space used?

Probably at some point deliberately cause a dump
during such a busy time on the machine and time
it (as root):

# sysctl debug.kdb.panic=1

> IIRC, the clock time in the top window when I
> pulled the plug was at least an hour tardy. 
> Could a crash dump take longer than that?

Was the light still blinking at the end of that hour?

> Anyway, buildworld was restarted and is back to
> building libraries. I'll be a lot more circumspect



===
Mark Millard
marklmi at yahoo.com