Re: specfs/spec_vnops.c diagnostic assertion panic

[Taylor R Campbell <campbell+netbsd-current-users%mumble.net@localhost>]

> Date: Sat, 13 Aug 2022 02:13:23 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
> 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?