Re: Armv7 unresponsive with flashing disk light

On Fri, Apr 25, 2025 at 09:28:54PM -0700, Mark Millard wrote:
> 
> 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: "?
> 
I see:
# sysctl debug kern.coredump | grep dump
debug.minidump: 1
debug.dump_modinfo: 
debug.elf32_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.pending: 0
kern.coredump: 1


> Media type for partition/slice with the swap
> space used?
> 
It's /dev/da0s2b, a mechanical USB hard disk:
# dmesg | grep da0
Trying to mount root from ufs:/dev/da0s2a []...
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <External USB3.0 0204> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 201703310007F
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
# 


> 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

The idea of deliberately triggering a panic seems like a
good sanity test. 
 
> Was the light still blinking at the end of that hour?

The activity light was blinking steadily when I noticed
that the machine was stuck and the time in the top window  
had stopped updating. The LED cadence was steady, as if in 
a short loop. Top was running on the serial console, but 
that hasn't inhibited messages and nothing apart from login
failures were showing. 

Thanks for writing!

bob prohaska