Hi,
I've fixed the problem for zfs, you'll need an updated kernel
(src/sys/kern/subr_pool.c) and the zfs module sources
(src/external/....). Can you confirm it works for you?
I can repeat the raidframe path too, I'm working on a fix there.
Jaromir
Le ven. 19 juin 2020 à 13:40, Frank Kardel <kardel%netbsd.org@localhost> a écrit :
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.