kern/54618: Recurring kernel panics during shutdown (9.99.15/amd64)

[david%gutteridge.ca@localhost]

>Number:         54618
>Category:       kern
>Synopsis:       Recurring kernel panics during shutdown (9.99.15/amd64)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 14 21:25:00 +0000 2019
>Originator:     David H. Gutteridge
>Release:        9.99.15
>Organization:
>Environment:
NetBSD arcusxvi.nonus-porta.net 9.99.15 NetBSD 9.99.15 (GENERIC) #5: Tue Oct  8 22:53:28 EDT 2019  disciple%arcusxvi.nonus-porta.net@localhost:/home/disciple/netbsd-current/src/sys/arch/amd64/compile/obj/GENERIC amd64

>Description:
I've encountered this panic during the shutdown process a few times
recently, with HEAD kernels of an October 1st and October 8th vintage.
I can't consistently duplicate it; it only seems to happen after there
has been a appreciable amount of disk activity (e.g. a bunch of pkgsrc
builds). This is on an oldish Ivy Bridge laptop I use for testing and
such.

I haven't had time to look into it any further, but suspect I can get
this to happen again, to get more details. Each time the backtrace is
essentially the same, the only difference is the CPU it's running on.
Anyway, I thought I'd mention it. Maybe someone else knows more
already.

[  9688.139991] syncing disks... [ 9688.1399915] Skipping crash dump on recursive panic
[  9688.139991] panic: lock error: Reader / writer lock: rw_vector_enter,350: locking against myself: lock 0xffff9986d4b623a0 cpu 0 lwp 0xffff9986cd64ab40
[  9688.139991] cpu0: Begin traceback...
[  9688.139991] vpanic() at netbsd:vpanic+0x160
[  9688.139991] snprintf() at netbsd:snprintf
[  9688.139991] lockdebug_abort() at netbsd:lockdebug_abort+0xee
[  9688.149995] rw_vector_enter() at netbsd:rw_vector_enter+0x3b0
[  9688.149995] exit1() at netbsd:exit1+0xf8
[  9688.159998] lwp_exit() at netbsd:lwp_exit+0x4aa
[  9688.159998] sigswitch() at netbsd:sigswitch+0x329
[  9688.159998] issignal() at netbsd:issignal+0x216
[  9688.159998] sleepq_block() at netbsd:sleepq_block+0x157
[  9688.170002] cv_timedwait_sig() at netbsd:cv_timedwait_sig+0x107
[  9688.170002] ttysleep() at netbsd:ttysleep+0x7b
[  9688.170002] ttywait_timo() at netbsd:ttywait_timo+0x8a
[  9688.180005] exit1() at netbsd:exit1+0x7f4
[  9688.180005] sigexit() at netbsd:sigexit+0x20a
[  9688.190009] sendsig() at netbsd:sendsig
[  9688.190009] lwp_userret() at netbsd:lwp_userret+0x19b
[  9688.190009] syscall() at netbsd:syscall+0x1ed
[  9688.200013] --- syscall (number 54) ---
[  9688.200013] 78e23df818d8:
[  9688.200013] cpu0: End traceback...
[  9688.200013] fatal breakpoint trap in supervisor mode
[  9688.200013] trap type 1 code 0 rip 0xffffffff8021dd9d cs 0x8 rflags 0x202 cr2 0x7dbfb0bd56f0 ilevel 0 rsp 0xffff9b0068c5e910
[  9688.200013] curlwp 0xffff9986cd64ab40 pid 603.1 lowest kstack 0xffff9b0068c5b2c0

>How-To-Repeat:
(As above, it seems a certain amount of intensive disk activity is
required, but I'm not sure about that.)
>Fix: