Bug 226130 - [zfs] [panic] solaris assert: zrl->zr_refcount == 0 (0x1 == 0x0)
Summary: [zfs] [panic] solaris assert: zrl->zr_refcount == 0 (0x1 == 0x0)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 22:40 UTC by Keith White
Modified: 2018-02-27 15:21 UTC (History)
1 user (show)

See Also:


Attachments
Console boot log (9.99 KB, text/plain)
2018-02-22 22:40 UTC, Keith White
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Keith White 2018-02-22 22:40:48 UTC
Created attachment 190909 [details]
Console boot log

I'm getting panics similar to Bug 204037 on a recent build for RPI2 (RPI3 in 32-bit mode) on a system shutdown or "zpool export ..."

root@rpi3uk:~ # zpool export tank
panic: solaris assert: zrl->zr_refcount == 0 (0x1 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c, line: 65
cpuid = 1
time = 1519336773
KDB: stack backtrace:
db_trace_self() at db_trace_self
         pc = 0xc0514f0c  lr = 0xc0097e00 (db_trace_self_wrapper+0x30)
         sp = 0xd95e5be8  fp = 0xd95e5d00
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
         pc = 0xc0097e00  lr = 0xc0229360 (vpanic+0x154)
         sp = 0xd95e5d08  fp = 0xd95e5d28
         r4 = 0x00000100  r5 = 0x00000001
         r6 = 0xda182b4d  r7 = 0xc07f7330
vpanic() at vpanic+0x154
         pc = 0xc0229360  lr = 0xc02293f8 (kproc_shutdown)
         sp = 0xd95e5d30  fp = 0xd95e5d34
         r4 = 0xd9f98888  r5 = 0xda9f4427
         r6 = 0xd9f988b4  r7 = 0xdb24d4b0
         r8 = 0xd9f98888  r9 = 0x00000000
        r10 = 0x00000002
kproc_shutdown() at kproc_shutdown
         pc = 0xc02293f8  lr = 0xda182138 ($d.7)
         sp = 0xd95e5d3c  fp = 0xd95e5d60
         r4 = 0xc02293f8  r5 = 0xd95e5d3c
$d.7() at $d.7
         pc = 0xda182138  lr = 0xda93ee64 (zrl_destroy+0x4c)
         sp = 0xd95e5d68  fp = 0xd95e5d88
zrl_destroy() at zrl_destroy+0x4c
         pc = 0xda93ee64  lr = 0xda89832c (dnode_buf_evict_async+0x9c)
         sp = 0xd95e5d90  fp = 0xd95e5db0
         r4 = 0xd9f98800 r10 = 0x00000002
dnode_buf_evict_async() at dnode_buf_evict_async+0x9c
         pc = 0xda89832c  lr = 0xc0283c44 (taskqueue_run_locked+0x12c)
         sp = 0xd95e5db8  fp = 0xd95e5de8
         r4 = 0xd9dbed00  r5 = 0xd9dbed2c
         r6 = 0xd9f98800  r7 = 0xd95e5dc0
         r8 = 0x00000001  r9 = 0x00000000
        r10 = 0xd95e5dc4
taskqueue_run_locked() at taskqueue_run_locked+0x12c
         pc = 0xc0283c44  lr = 0xc02849e0 (taskqueue_thread_loop+0xa0)
         sp = 0xd95e5df0  fp = 0xd95e5e20
         r4 = 0x00000000  r5 = 0xd9dbed00
         r6 = 0xd9dbed1c  r7 = 0xc05a0658
         r8 = 0xd9dbed2c  r9 = 0x00000100
        r10 = 0xc0875cc0
taskqueue_thread_loop() at taskqueue_thread_loop+0xa0
         pc = 0xc02849e0  lr = 0xc01ef474 (fork_exit+0xa0)
         sp = 0xd95e5e28  fp = 0xd95e5e40
         r4 = 0xda6e93a0  r5 = 0xc0875928
         r6 = 0xc0284940  r7 = 0xd87a6e60
         r8 = 0xd95e5e48  r9 = 0x00000000
fork_exit() at fork_exit+0xa0
         pc = 0xc01ef474  lr = 0xc05178a8 (swi_exit)
         sp = 0xd95e5e48  fp = 0x00000000
         r4 = 0xc0284940  r5 = 0xd87a6e60
         r6 = 0xc06e800c  r7 = 0xc4b86ae0
         r8 = 0xc06e80d0 r10 = 0xc0875cc0
swi_exit() at swi_exit
         pc = 0xc05178a8  lr = 0xc05178a8 (swi_exit)
         sp = 0xd95e5e48  fp = 0x00000000
KDB: enter: panic
[ thread pid 0 tid 100116 ]
Stopped at      $d.3:   ldrb    r15, [r15, r15, ror r15]!
db> reboot
Comment 1 Keith White 2018-02-22 23:21:13 UTC
FWIW: a build at r329839 does not exhibit this problem. Sorry for the noise.
Comment 2 Keith White 2018-02-27 11:51:46 UTC
Update, more noise, panics still occur if kernel built on the rpi3-32.

FreeBSD 12.0-CURRENT #0 r329986M: Mon Feb 26 06:49:59 EST 2018
    freebsd@rpi3uk:/usr/obj/usr/src/arm.armv7/sys/RPI2-CD arm
FreeBSD clang version 6.0.0 (branches/release_60 325330) (based on LLVM 6.0.0)
...
panic: solaris assert: atomic_add_64_nv(&arc_loaned_bytes, 0) >= 0 (0xfffffffffffffa00 >= 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: 2829
cpuid = 2
time = 1519646945
KDB: stack backtrace:
db_trace_self() at db_trace_self
...

Identical tree cross-built on my laptop (and then installed on rpi3 does not panic. Yet.

FreeBSD 12.0-CURRENT #6 r329986M: Mon Feb 26 15:19:42 EST 2018
    root@e6220:/usr/obj/usr/src/arm.armv7/sys/RPI2-CD arm
FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)


Perhaps there is something wrong with my native build environment not "doing the right thing" with atomics.

I have a workaround at least: cross build.