Bug #1030
open
msdosfs umount panic
Description
Hey,
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
system.
panic: assertion: dep == deq in msdosfs_hashrem
#0 dumpsys () at ./machine/thread.h:83
#1 0xc018a40c in boot (howto=256) at
/usr/build/src/sys/kern/kern_shutdown.c:375
#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
/usr/build/src/sys/kern/vfs_subr.c:1296
#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
/usr/build/src/sys/kern/vfs_mount.c:983
#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
/usr/build/src/sys/kern/vfs_syscalls.c:705
#13 0xc01e0051 in sys_unmount (uap=0xe593fcf0) at
/usr/build/src/sys/kern/vfs_syscalls.c:590
#14 0xc02a91ce in syscall2 (frame=0xe593fd40) at
/usr/build/src/sys/platform/pc32/i386/trap.c:1374
#15 0xc029a166 in Xint0x80_syscall () at
/usr/build/src/sys/platform/pc32/i386/exception.s:876
cheers
simon
Updated by tuxillo about 15 years ago
Hi all,
Type: VM inside VMware
Release: 2.3.2 (Aug, 19)
Mem: 256MB
I've done the following:
(sysid=11 which is FAT)dd if=/dev/zero of=msdos.img bs=1m count=100
sudo vnconfig vn0 msdos.img
fdisk -i vn0
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.
1676
- 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.
Updated by tuxillo almost 11 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
Hi,
Checked with:
- 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:
- dd if=/dev/zero of=test5.img bs=1m count=512
dd: test5.img: No space left on device - df -h .
Filesystem Size Used Avail Capacity Mounted on
/dev/vkd1 4.0G 4.0G 1.0M 100% /mnt - umount /mnt
kthread 0x800b440600 syncer9 has exited
Couldn't reproduce it.
Cheers,
Antonio Huete
Updated by tuxillo almost 11 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."
Grabbing.