Every so often (about one out of every two or three umounts), the umount will get stick in the oldumount syscall (I did a systrace). This happens on encrypted loopback ext3, regular loopback vfat, and ext2. I've not tried it on any other file systems, but the fact that it applies to three different ones makes me believe it's not file system specific. I've experience the bug in gentoo-sources (progressively as I updated from 2.4.18, to 2.4.19, to 2.4.20), pfeifer-sources (I used a few of the 2.4.20 prereleases), and my custom patched vanilla sources (I'm currently using 2.4.21, the core ck3 patch, a few of the tuning patches for the hertz setting, rmap vm, loop aes (versus cryptoapi in all the previous kernels), and the address space split patch). I've experienced this with or without himem and with 3GB/1GB or 2GB/2GB address split. In all situations, I had O(1), low latency patches, and preemptive enabled. I've used various hertz settings (100, 200, 500, and 1000). The actual umount progresses as follows: umount /mnt/point <hang> On another terminal, a run of df shows the mount point as having the same statistics as the root file system (in all cases, the mount point has been on the root file system, so it may be a sign that it's showing the underlying file system more than the root file system). A combination of icewm's graphing and top show's that umount is using up 100% (or at least, trying). In some cases, doing snice -20 umount has resulted in the umount process quickly completing. In other cases, it has had not any effect in causing the umount process to complete. The umount eventually returns successfully after aproximately 30 minutes in the worst case. Because I've not heard of this bug being reported by anyone else, I believe it possible it is partially a hardware/driver problem, but I do not know where to begin. If no one else reports having a similar problem, I would appreciate any support in learning to debug the kernel so that I might be able to track down the source of this problem.
Experiencing the same bug, so it probably is not hardware. It happened twice to me with gaming-sources, never with vanilla, maybe it resides in the ck patchset?
With the amount of patches you've tried, this does look like something ck-related... Does this occur any longer with the current ck patchsets?
I get it too now.. My USB-memory hangs. Things it is something in the sys-apps/baselayout-1.8.6.13 that made it fail, because it worked before I emerged the latest version. Very annoying.
Can you downgrade baselayout to proove your theory?
Has anything happened with this bug? Is the issue resolved, possibly with a newer kernel? Or a baselayout change as Claes suggested?
This bug is two months old since any activity. I'm marking fixed since we haven't heard back from them.
I'm experiencing similar problem on my system since some days (2-4). umount completely freeze my system (did'nt wait 30 mins so see if ok then). One of the latest thing I recently modified is switch from devfs to udev (udev-045). I remember I never had such problems before. my system: # emerge info Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 12 2005, 23:53:06)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.7.9, 1.4_p6, 1.9.4, 1.5, 1.8.5-r2, 1.6.3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r3 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks notitles sandbox sfperms" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/src/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X alsa apm arts avi berkdb bitmap-fonts cdr crypt cupsdvd dvdr encode f77 flac font-server foomaticdb fortran gdbm gif gtk gtk2 imagemagick imlib jpeg kde libg++ libwww mad mikmod mmx motif mpeg ncurses oggvorbis oss pam pdflib perl png ppds python qt quicktime readline scanner sdl sse ssl tcpd tiff truetype truetype-fonts type1-fonts usb xml2 xmms xv zlib linguas_fr linguas_en" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
... forgot to tell: umount command did'nt freeze the system every time. 1 of 4-8. "at random". Perhaps race condition between udev, rules to alias devices and flags in fstab. I'm using USB peripherals (digital camera, 2 external USB2 hard drives) or CD / DVD and frequently doing mount / umount. Every devices have similar system config: - fstab contains for every devices a line like: /dev/[device] /mnt/[mount_point] [fs_type] noauto,user[,ro sometimes] 0 0 - each [device] is created by udev as an alias in /dev root (eg: /dev/cdrom, or /dev/usb_seagate1, /dev/usb_nikon_5000)
