Bug #1014
closed
panic when umounting a msdosfs mount: "VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0"
0%
Description
After playing with my mobile phone (mounted it's memory card with mount -t
msdosfs), a umount triggered the panic (well, I did run sync a second or 2
before doing a umount). The memory dump is at leaf:~rumko/crash/19.05.2008/
and the backtrace (including the kernel message buffer that kgdb prints) is
here:
Unread portion of the kernel message buffer:
panic: VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0
mp_lock = 00000001; cpuid = 1
boot() called on cpu#1
syncing disks... 3 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue
timeout - completing request directly
ad8: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12361855
done
Uptime: 21h9m5s
dumping to dev #ad/0x20041, blockno 4204800
dump 2046 2045 ... 1 0
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc02733c5 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc0273688 in panic (fmt=0xc0521f34 "VOP_STDCLOSE: BAD WRITECOUNT %p %d\n")
at /usr/src/sys/kern/kern_shutdown.c:800
#3 0xc02b55f5 in vop_stdclose (ap=0xf49f0bf8)
at /usr/src/sys/kern/vfs_default.c:1191
#4 0xc02caf0f in spec_close (ap=0xf49f0bf8)
at /usr/src/sys/vfs/specfs/spec_vnops.c:763
#5 0xc03c3e6e in ufsspec_close (ap=0xf49f0bf8)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:1947
#6 0xc03c1f44 in ufs_vnoperatespec (ap=0xf49f0bf8)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:2462
#7 0xc02c5f8e in vop_close (ops=0xd3a0c150, vp=0xf2629e68, fflag=3)
at /usr/src/sys/kern/vfs_vopops.c:257
#8 0xc02cf827 in msdosfs_unmount (mp=0xda422060, mntflags=0)
at /usr/src/sys/vfs/msdosfs/msdosfs_vfsops.c:672
#9 0xc02c2f7a in dounmount (mp=0xda422060, flags=0)
at /usr/src/sys/kern/vfs_syscalls.c:705
#10 0xc02c31c7 in sys_unmount (uap=0xf49f0cf0)
at /usr/src/sys/kern/vfs_syscalls.c:590
#11 0xc049a37d in syscall2 (frame=0xf49f0d40)
at /usr/src/sys/platform/pc32/i386/trap.c:1349
#12 0xc0487be6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#13 0x0804ace8 in ?? ()
--
Regards,
Rumko
Updated by dillon almost 16 years ago
:After playing with my mobile phone (mounted it's memory card with mount t
:msdosfs), a umount triggered the panic (well, I did run sync a second or 2
:before doing a umount). The memory dump is at leaf:~rumko/crash/19.05.2008/
:and the backtrace (including the kernel message buffer that kgdb prints) is
:here:
:
:Unread portion of the kernel message buffer:
:panic: VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0
:
:mp_lock = 00000001; cpuid = 1
:boot() called on cpu#1
:
:syncing disks... 3 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue
:timeout - completing request directly
:ad8: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12361855
:
:done
:-
:Regards,
:Rumko
Did you mount it normally or use options like -o ro (read-only), or
-u (update) at any point ?And, is the panic reproducable?-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by rumcic almost 16 years ago
Matthew Dillon wrote:
If I remember correctly, I did mount it readonly, then did a umount -u, copied
a file, ran sync (I'm not sure, but could've been more than one time) and
tried umount-ing it.
As for being reproducable ... I can try it again, if the need to reproduce it
arises.
--
Regards,
Rumko
Updated by dillon almost 16 years ago
:If I remember correctly, I did mount it readonly, then did a umount u, copied
:a file, ran sync (I'm not sure, but could've been more than one time) and
:tried umount-ing it.
:
:As for being reproducable ... I can try it again, if the need to reproduce it
:arises.
:-
:Regards,
:Rumko
Being able to reproduce it allows you to test to see if my patch fixes
the problem!However, in this case you don't need to worry about it. I can reproduce
the bug from the information you have given me and I will commit a fix
to HEAD very soon.-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by rumcic almost 16 years ago
Matthew Dillon wrote:
Well, my plan was to reserve a couple of hours after you'd send a patch and
first update to HEAD again and try to reproduce it and apply the patch and
try again ...
-
Regards,
Rumko
Updated by rumcic almost 16 years ago
Rumko wrote:
Well after that commit to HEAD, I can't reproduce the panic anymore (did play
quite a lot with that mount, but it worked without problems).
--
Regards,
Rumko
Updated by matthias over 15 years ago
Committed fix works according to rumcic, so close the issue