Summary: | [zfs] panic: Assertion lock == sq->sq_lock when sending ZFS snapshot | ||
---|---|---|---|
Product: | Base System | Reporter: | Xin LI <delphij> |
Component: | kern | Assignee: | freebsd-fs (Nobody) <fs> |
Status: | Open --- | ||
Severity: | Affects Some People | CC: | asomers, delphij, fs, grahamperrin, jhb, markj, mav, mmacy |
Priority: | --- | Keywords: | crash, needs-qa |
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Xin LI
![]() ![]() I'm not able to repro this. Is it still occurring? I just experienced the same panic, though with a different stack trace. In my case I was using a build based on stable/13 from September-2021 panic: Assertion lock == sq->sq_lock failed at /usr/home/asomers/src/github/Axcient/freebsd-src/sys/kern/subr_sleepqueue.c:371 cpuid = 21 time = 1651466741 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x47/frame 0xfffffe0a7468ad20 vpanic() at vpanic+0x1cc/frame 0xfffffe0a7468ad80 panic() at panic+0x43/frame 0xfffffe0a7468ade0 sleepq_add() at sleepq_add+0x4ae/frame 0xfffffe0a7468ae40 _sleep() at _sleep+0x2b0/frame 0xfffffe0a7468aee0 taskqueue_quiesce() at taskqueue_quiesce+0x1f3/frame 0xfffffe0a7468af50 dmu_objset_sync() at dmu_objset_sync+0x57a/frame 0xfffffe0a7468b030 dsl_dataset_sync() at dsl_dataset_sync+0x218/frame 0xfffffe0a7468b080 dsl_pool_sync() at dsl_pool_sync+0x17f/frame 0xfffffe0a7468b110 spa_sync() at spa_sync+0x15ee/frame 0xfffffe0a7468b350 txg_sync_thread() at txg_sync_thread+0x346/frame 0xfffffe0a7468b430 fork_exit() at fork_exit+0xb3/frame 0xfffffe0a7468b470 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0a7468b470 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic (In reply to Alan Somers from comment #2) Were you able to get a kernel dump? It would useful to see the contents of *sq->sq_lock from the sleepq_add() frame. (In reply to Mark Johnston from comment #3) I only got a text dump, unfortunately. I'm going to try again, this time with full core dumps enabled. |