ZFS v28 recv panic

[James R. Van Artsdalen]

The following series of commands cause a kernel panic with pjd's 8/31
zfs v28 patches on svn 212080:

    zpool create rec1 da3
    zpool create rec2 da4

    zfs create rec1/a
    zfs create rec1/a/b
    zfs snapshot -r rec1 at s1

    zfs rename rec1/a/b rec1/c
    zfs destroy -r rec1/a
    zfs create rec1/a
    zfs rename rec1/c rec1/a/d
    zfs snapshot -r rec1 at s2

    zfs send -R rec1 at s1 | zfs recv -dvuF rec2

    zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2

(this is an attempt to wreak havoc on zfs send/recv by having a child
dataset that is older than the parent, but it tickles a kernel bug
rather than the zfs recv code)

The textdump.tar file is available upon request.  The panic string is:

solaris assert: vp->v_count == 1, file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
line: 4510


The kernel config file:

kraken:/root# cat /usr/src/sys/amd64/conf/BIGTEX
include     GENERIC
ident         BIGTEX

nodevice    hptrr        # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx

#options        PRINTF_BUFR_SIZE=128

nodevice         uhid            # "Human Interface Devices"

options         DEBUG_LOCKS
options         DEBUG_VFS_LOCKS
kraken:/root#

-------------- next part --------------
include 	GENERIC
ident 		BIGTEX

nodevice	hptrr		# Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx

#options		PRINTF_BUFR_SIZE=128

nodevice         uhid            # "Human Interface Devices"

options         DEBUG_LOCKS
options         DEBUG_VFS_LOCKS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: textdump.tar.1
Type: application/octet-stream
Size: 121856 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20101006/c20456cc/textdump.tar-0001.obj