On 16 May 2017, at 19:58, Andriy Gapon wrote: > On 16/05/2017 16:49, Kristof Provost wrote: >> On 16 May 2017, at 15:41, Andriy Gapon wrote: >>> On 10/05/2017 12:37, Kristof Provost wrote: >>>> I have a reproducible panic on CURRENT (r318136) doing >>>> (jupiter) # zfs send -R -v zroot/var_at_before-kernel-2017-04-26 | nc >>>> dual 1234 >>>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>>> >>>> For clarity, the receiving machine is CURRENT r318136, the sending >>>> machine is >>>> running a somewhat older CURRENT version. >>>> >>>> The receiving machine panics a few seconds in: >>>> >>>> receiving full stream of zroot/var_at_before-kernel-2017-04-03 into >>>> tank/jupiter/var_at_before-kernel-2017-04-03 >>>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) >>>> (0x0 == >>>> 0x1), file: >>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>>> line: 2007 >>> >>> could you please try to revert commits related to the compressed >>> send and see if >>> that helps? I assume that the sending machine does not have (does >>> not use) the >>> feature while the target machine is capable of the feature. >>> >>> The commits are: r317648 and r317414. Mot that I really suspect >>> that change, >>> but just to eliminate the possibility. >> >> Those commits appear to be the trigger. >> I’ve not changed the sender, but with those reverted I don’t see >> the panic any >> more. > > Thank you for testing. > Do you still have the old kernel / module and the crash dump? > It would interesting to poke around in frame 14. > > This contains the kernel and crash files: https://www.sigsegv.be/files/zfs_recv_kernel_crash.tar.bz2 I was running r318356 at the time of this panic. Regards, KristofReceived on Tue May 16 2017 - 16:53:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC