Bug 181966

Summary: [zfs] [panic] Kernel panic in ZFS I/O: solaris assert: BP_EQUAL(bp, &zio->io_bp_orig); zio.c line 2955 [9.2/amd64]
Product: Base System Reporter: Charlie <3zstbn24xn>
Component: kernAssignee: freebsd-fs (Nobody) <fs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: avg
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Charlie 2013-09-09 16:20:00 UTC
In the middle of normal read/write I/O, with a scrub running in the background, the ZFS layer caused the system to panic after triggering the following assertion:

panic: solaris assert: BP_EQUAL(bp, &zio->io_bp_orig), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2955
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff80947966 at kdb_backtrace+0x66
#1 0xffffffff8090d98e at panic:0x1ce
#2 0xffffffff8196b12a at assfail+0x1a
#3 0xffffffff818a1280 at zio_done:0x120
#4 0xffffffff8189ee73 at zio_execute+0xc3
#5 0xffffffff80954534 at taskqueue_run_locked+0x74
#6 0xffffffff809554e6 at taskqueue_thread_loop+0x46
#7 0xffffffff808db65f at fork_exit+0x11f
#8 0xffffffff80cdc19e at fork_trampoline+0xe

This is on a RAID-Z3 twelve drive ZFS array with the individual providers using GELI.  It's an amd64 system (Intel Core 2, multiple cores).

Fix: 

Unknown.
How-To-Repeat: Have a RAID-Z3 ZFS array on twelve drives over GELI.  Had a zpool scrub running in the background and some read/write I/O.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-09-13 23:36:50 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

overs
Comment 2 Garrett Wollman 2014-04-10 11:14:12 UTC
Just hit this bug, with the following (apparently identical) stack
trace on a 9.2 system:

panic: solaris assert: BP_EQUAL(bp, &zio->io_bp_orig), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2955
cpuid = 20
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff98a38d2900
kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff98a38d29c0
panic() at panic+0x1ce/frame 0xffffff98a38d2ac0
assfail() at assfail+0x1a/frame 0xffffff98a38d2ad0
zio_done() at zio_done+0x120/frame 0xffffff98a38d2b30
zio_execute() at zio_execute+0xc3/frame 0xffffff98a38d2b70
taskqueue_run_locked() at taskqueue_run_locked+0x74/frame 0xffffff98a38d2bc0
taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame 0xffffff98a38d2be0
fork_exit() at fork_exit+0x11f/frame 0xffffff98a38d2c30
fork_trampoline() at fork_trampoline+0xe/frame 0xffffff98a38d2c30
--- trap 0, rip = 0, rsp = 0xffffff98a38d2cf0, rbp = 0 ---

No debugger or dump partition configured, so all I could do is let it
reboot.

-GAWollman
Comment 3 Andriy Gapon freebsd_committer 2018-01-09 09:57:21 UTC
Not sure why this bug is marked as in progress.
The code in supported version of FreeBSD is quite different from 9.x era.
Please re-open if the problem happens again.