Bug 134496 - [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt")
Summary: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: neg...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Pawel Jakub Dawidek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 21:10 UTC by Thomas Backman
Modified: 2009-09-28 18:52 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Backman 2009-05-12 21:10:03 UTC
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.)
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-05-12 21:13:56 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 K. Macy freebsd_committer freebsd_triage 2009-05-17 05:26:54 UTC
State Changed
From-To: open->feedback


waiting for feedback
Comment 3 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:03:43 UTC
State Changed
From-To: feedback->closed

I don't believe this problem still exists and I cannot reproduce it with 
proposed procedure. Let me know if the problem still exists in 8.0. 


Comment 4 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:03:43 UTC
Responsible Changed
From-To: freebsd-fs->pjd

I'll take this one.