Re: Armv7 unresponsive with flashing disk light
- Reply: bob prohaska : "Re: Armv7 unresponsive with flashing disk light"
- In reply to: bob prohaska : "Re: Armv7 unresponsive with flashing disk light"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 26 Apr 2025 04:28:54 UTC
On Apr 25, 2025, at 17:54, bob prohaska <fbsd@www.zefox.net> wrote: > On Fri, Apr 25, 2025 at 05:02:36PM -0700, Mark Millard wrote: >> >> >> On Apr 25, 2025, at 16:12, Robert Clausecker <fuz@fuz.su> 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