> Date: Sat, 13 Aug 2022 02:13:23 +0700 > From: Robert Elz <k...@munnari.oz.au> > > Apart from dkctl() and the two fsck_ffs processes, there was > the parent fsck (just in wait) and (or course) init, and a whole > set of sh processes (many in pipe_rd or similar) - which will be > the infrastructure used for running rc scripts. There's also devpubd > (in wait) and sleep (in nanoslp). That's it (and of course, lots and > lots of kernel threads - things with pid==0).
This is interesting -- I think what happened is that fsck and the dkctl in devpubd's hooks/02-wedgenames may have run concurrently. (Can't find anything else that might run dkctl asynchronously at boot.) Might help to know what the process command-lines were for fsck and dkctl if you catch it again (possibly without the patch I just sent in a followup, in case that fixes the kernel crash). Can you share dmesg, `drvctl -lt' output, and /etc/rc.conf (or any other /etc/rc* configuration)? Can you describe all the physical and logical storage devices on your system? (Privately is fine if you prefer.) Do you have any removable media that get detected asynchronously at boot so devpubd might have finished starting up and started listening for events in the background by the time that the medium appears but just before fsck starts opening disks?