Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 May 2009 20:08:21 GMT
From:      Thomas Backman <serenity@exscape.org>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/134496: ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt")
Message-ID:  <200905122008.n4CK8Lle095732@www.freebsd.org>
Resent-Message-ID: <200905122010.n4CKA3xD011084@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         134496
>Category:       kern
>Synopsis:       ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt")
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 12 20:10:03 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Thomas Backman
>Release:        7.2-RELEASE
>Organization:
exscape
>Environment:
FreeBSD vmware.exscape.org 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue May 12 21:31:14 CEST 2009     root@vmware.exscape.org:/tank/usr/obj/tank/usr/src/sys/GENERIC  amd64
>Description:
Plain GENERIC kernel, no change whatsoever. Same deal on two wholly computers (A64 3200+, nForce4 mobo, 2GB DDR; Macbook Pro C2D + VMware Fusion).

Broken backtrace from the original box:

# kgdb kernel.debug /var/crash/ZFS_CRASH.vmcore 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: vrele: negative ref cnt
cpuid = 0
Uptime: 10m26s
Physical memory: 2031 MB
Dumping 133 MB: 118 102 86 70 54 38 22 6

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/smbfs.ko...Reading symbols from /bootdir/boot/kernel/smbfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbfs.ko
Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from /bootdir/boot/kernel/libiconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libiconv.ko
Reading symbols from /boot/kernel/libmchain.ko...Reading symbols from /bootdir/boot/kernel/libmchain.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libmchain.ko
Reading symbols from /boot/kernel/geom_gate.ko...Reading symbols from /bootdir/boot/kernel/geom_gate.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_gate.ko
#0  doadump () at pcpu.h:195
195             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xffffffff80517f28 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xffffffff8051836c in panic (fmt=0xffffffff808c902c "vrele: negative ref cnt") at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xffffffff8059c7f4 in vrele (vp=0x0) at /usr/src/sys/kern/vfs_subr.c:2146
#4  0xffffffff804e615e in fdfree (td=0xffffff0002ab8a50) at /usr/src/sys/kern/kern_descrip.c:1777
#5  0xffffffff804f2bf3 in exit1 (td=0xffffff0002ab8a50, rv=0) at /usr/src/sys/kern/kern_exit.c:284
#6  0xffffffff804fe093 in kthread_exit (ecode=0) at /usr/src/sys/kern/kern_kthread.c:149
#7  0xffffffff80d2479d in spa_async_thread () from /boot/kernel/zfs.ko
#8  0x0000000000000000 in ?? ()
#9  0xffffff0002ab8a50 in ?? ()
#10 0xfffffffebe80bc80 in ?? ()
#11 0xffffff001007b478 in ?? ()
#12 0xffffff001044c800 in ?? ()
#13 0xfffffffebe80bc70 in ?? ()
#14 0xffffffff804f433f in fork_exit (callout=Cannot access memory at address 0xffffffffffffffc0
) at /usr/src/sys/kern/kern_fork.c:810
Previous frame inner to this frame (corrupt stack?)

>How-To-Repeat:
(Using bash)
# zpool create crash daX
# zpool export crash
# while :; do zpool import crash; zpool export crash; done
(Needless to say, I hope, this also happens in real-world scenarios, including when doing a regular shutdown.)
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905122008.n4CK8Lle095732>