kern/58043: kernel crash in -current

[paul%whooppee.com@localhost]

>Number:         58043
>Category:       kern
>Synopsis:       kernel crash in assert_sleepable() in -current, dk(4) driver?
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 16 15:05:00 +0000 2024
>Originator:     Paul Goyette
>Release:        NetBSD 10.99.10
>Organization:
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
| (Retired)           | 1B11 1849 721C 56C8 F63A | paul%whooppee.com@localhost    |
| Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette%netbsd.org@localhost  |
| & Network Engineer  |                          | pgoyette99%gmail.com@localhost |
+---------------------+--------------------------+----------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 10.99.10 NetBSD 10.99.10 (SPEEDY 2024-03-13 18:25:47 UTC) #0: Wed Mar 13 20:05:25 UTC 2024 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
	At unpredictable times, but always under heavy disk load (ie,
	build.sh runnning with -j30) I am seeing random crashes.  I
	have a crash dump from one of these crashes, and stack trace
	seems to implicate the disk driver:

	Crash version 10.99.10, image version 10.99.10.
	crash: _kvm_kvatop(0)
	Kernel compiled without options LOCKDEBUG.
	System panicked: dump forced via kernel debugger
	Backtrace from time of crash is available.
	crash> bt
	end() at 0
	kern_reboot() at kern_reboot+0x87
	db_sync_cmd() at db_sifting_cmd
	db_command() at db_command+0x123
	db_command_loop() at db_command_loop+0x1c7
	db_trap() at db_trap+0xcc
	kdb_trap() at kdb_trap+0x106
	trap() at trap+0x2de
	--- trap (number 1) ---
	breakpoint() at breakpoint+0x5
	vpanic() at vpanic+0x173
	panic() at printf_nostamp
	assert_sleepable() at assert_sleepable+0x99
	pool_cache_get_paddr() at pool_cache_get_paddr+0x13c
	end() at ffffffff813ad275
	bdev_strategy() at bdev_strategy+0x81
	spec_strategy() at spec_strategy+0x6e
	VOP_STRATEGY() at VOP_STRATEGY+0x3c
	dkstart() at dkstart+0x13e
	dkiodone() at dkiodone+0xa6
	lddone() at lddone+0x10
	nvme_q_complete() at nvme_q_complete+0xff
	softint_dispatch() at softint_dispatch+0x112
	DDB lost frame for Xsoftintr+0x4c, trying 0xffffd220dfd9d0f0
	Xsoftintr() at Xsoftintr+0x4c
	--- interrupt ---
	0:

	I've had several other similar crashes, although I haven't
	saved dump details.  All stack traces seem to have pointed
	in the same area, and all fail at the assert_sleepable().

	Config and/or dmesg are available.  One item of note is that
	this machine contains multiple SSDs, and in one case I have
	a ccd(4) of two 2-TB CCD partitions (each of which occupies
	a complete SSD device).

>How-To-Repeat:
	No specific recipe to reproduce, it is seeming random when
	under high disk activity.
>Fix:
	Please.  In fact, pretty-please.

>Unformatted: