Good. I found another subsystem triggering the assertion. Try "fdisk raidX" to panic like this:[ 300.6631030] panic: kernel diagnostic assertion "(req->req_bp->b_flags & B_PHYS) != 0" failed: file "/src/NetBSD/cur/src/sys/arch/xen/xen/xbd_xenbus.c", line 1373
[ 300.6631030] cpu2: Begin traceback... [ 300.6631030] vpanic() at netbsd:vpanic+0x152 [ 300.6631030] __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax [ 300.6631030] xbd_diskstart() at netbsd:xbd_diskstart+0x7c2 [ 300.6631030] dk_start() at netbsd:dk_start+0xef [ 300.6730966] rf_DispatchKernelIO() at netbsd:rf_DispatchKernelIO+0x1a8 [ 300.6730966] rf_DiskIOEnqueue() at netbsd:rf_DiskIOEnqueue+0x103 [ 300.6730966] FireNodeList() at netbsd:FireNodeList+0x67 [ 300.6730966] rf_DispatchDAG() at netbsd:rf_DispatchDAG+0x12e [ 300.6730966] rf_State_ExecuteDAG() at netbsd:rf_State_ExecuteDAG+0xcb [ 300.6730966] rf_ContinueRaidAccess() at netbsd:rf_ContinueRaidAccess+0xb4 [ 300.6730966] rf_DoAccess() at netbsd:rf_DoAccess+0x10c [ 300.6830965] raid_diskstart() at netbsd:raid_diskstart+0x100 [ 300.6830965] dk_start() at netbsd:dk_start+0xef [ 300.6830965] rf_RaidIOThread() at netbsd:rf_RaidIOThread+0x142 [ 300.6830965] cpu2: End traceback... [ 300.6830965] rebooting... Frank On 06/19/20 11:10, jdolecek%NetBSD.org@localhost wrote:
Synopsis: Xen pvh instance: zpool create on xbd* devices panics Responsible-Changed-From-To: kern-bug-people->jdolecek Responsible-Changed-By: jdolecek%NetBSD.org@localhost Responsible-Changed-When: Fri, 19 Jun 2020 09:10:34 +0000 Responsible-Changed-Why: Mine. The assertion is there to catch cases which trigger non-optimal xbd I/O, to weed out those from kernel code. I'll check how is it triggered by zfs.