Bug #1030


msdosfs umount panic

Added by corecode almost 16 years ago. Updated almost 3 years ago.

In Progress
VFS subsystem
Target version:
Start date:
Due date:
% Done:


Estimated time:



just happened when umounting my mp3 player. I had a "file system full"
before, in case this is important. dump way too large to upload. I'll be
away for bicycle tour the next weeks, so if you need details, sorry :) UP

panic: assertion: dep == deq in msdosfs_hashrem

#0 dumpsys () at ./machine/thread.h:83
#1 0xc018a40c in boot (howto=256) at
#2 0xc018a561 in panic (fmt=0xe5ab76b7 "assertion: %s in %s")
at /usr/build/src/sys/kern/kern_shutdown.c:800
#3 0xe5aaf8c2 in msdosfs_hashrem (dep=0xd8695b10)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_denode.c:208
#4 0xe5aaf927 in msdosfs_reclaim (ap=0xe593fa54)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_denode.c:679
#5 0xc01e36ac in vop_reclaim (ops=0xd4c0ca50, vp=0xdbc786e8)
at /usr/build/src/sys/kern/vfs_vopops.c:624
#6 0xc01d8858 in vclean_vxlocked (vp=0xdbc786e8, flags=8)
at /usr/build/src/sys/kern/vfs_subr.c:1154
#7 0xc01d88d9 in vgone_vxlocked (vp=0xdbc786e8) at
#8 0xc01da70a in vflush_scan (mp=0xdbb95918, vp=0xdbc786e8, data=0xe593fbdc)
at /usr/build/src/sys/kern/vfs_mount.c:1151
#9 0xc01da8dc in vmntvnodescan (mp=0xdbb95918, flags=2, fastfunc=0,
slowfunc=0xc01da690 <vflush_scan>, data=0xe593fbdc) at
#10 0xc01daa65 in vflush (mp=0xdbb95918, rootrefs=0, flags=0)
at /usr/build/src/sys/kern/vfs_mount.c:1094
#11 0xe5ab34c5 in msdosfs_unmount (mp=0xdbb95918, mntflags=0)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_vfsops.c:655
#12 0xc01dfd94 in dounmount (mp=0xdbb95918, flags=0) at
#13 0xc01e0051 in sys_unmount (uap=0xe593fcf0) at
#14 0xc02a91ce in syscall2 (frame=0xe593fd40) at
#15 0xc029a166 in Xint0x80_syscall () at


Actions #1

Updated by tuxillo over 14 years ago

Hi all,

Type: VM inside VMware
Release: 2.3.2 (Aug, 19)
Mem: 256MB

I've done the following:

dd if=/dev/zero of=msdos.img bs=1m count=100
sudo vnconfig vn0 msdos.img
fdisk -i vn0

(sysid=11 which is FAT)

sudo newfs_msdos /dev/vn0
sudo mount /dev/vn0 /mnt/test && cd /mnt/test

In order to reproduce the issue, I wanted to fill up the FS to then umount it,
but instead I found:

- A lot of messages in syslog: hammer_ip_add_bulk: reservation failed
> dmesg | grep ip_add_bulk |wc l
System almost unresponsive.
- Cannot break ^C (had to ^Z)

After supending the process, the system becomes intermittently unresponsive,
writting the hammer_ip_add_bulk message to syslog every 30 seconds more or less
(I think there's a sync by that time).

I will try to catch the kernel trace when that happens. I've been unable due
VMWare hotkeys, too bad.

Actions #2

Updated by tuxillo about 10 years ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Status changed from New to Feedback
  • Assignee deleted (0)
  • Target version set to 3.8


Checked with:

  1. newfs_msdos /dev/vkd1
    /dev/vkd1: 8372216 sectors in 1046527 FAT32 clusters (4096 bytes/cluster)
    bps=512 spc=8 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=8388608 bspf=8177 rdcl=2 infs=1 bkbs=2

Then multiple dd's until:

  1. dd if=/dev/zero of=test5.img bs=1m count=512
    dd: test5.img: No space left on device
  2. df -h .
    Filesystem Size Used Avail Capacity Mounted on
    /dev/vkd1 4.0G 4.0G 1.0M 100% /mnt
  3. umount /mnt
    kthread 0x800b440600 syncer9 has exited

Couldn't reproduce it.

Antonio Huete

Actions #3

Updated by tuxillo about 10 years ago

  • Status changed from Feedback to In Progress
  • Assignee set to tuxillo

corecode said:

"Unless the vnode code in msdosfs was fixed, this bug is probably still there. Not sure if it is so easy to reproduce."


Actions #4

Updated by tuxillo almost 3 years ago

  • Target version changed from 3.8 to 6.0

Also available in: Atom PDF