[lug] Mount process in uninterruptible sleep

[Chris Riddoch]

"Riggs, Rob" <RRiggs at doubleclick.net> writes:

> Your machine needs to be rebooted. Linux has had similar mount problems in
> the kernel all the way back to 1.x (and likely since inception). There are a
> number of things that can cause this. My guess would be that the vfat
> filesystem choked on the data in your disk image. (Are you sure it's vfat
> rather than msdos?)

It's a problem with '-t msdos', too.  I just ran an strace with it,
just to make sure...

$ sudo mount -t msdos -o loop ./disk.img ./mnt/

And after spewing out a bunch of normal-looking output, the last
couple lines are these:

ioctl(4, LOOP_SET_FD, 0x3)              = 0
ioctl(4, LOOP_SET_STATUS, 0xbffff3d0)   = 0
close(4)                                = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV], NULL, 8) = 0
mount("/dev/loop1", "./mnt/", "msdos", 0xc0ed0000, 0x805aee8

And the cursor blinks at the end of the last line.

> If this hang can be repeated on the most recent kernel in the series you are
> using (2.2 or 2.4), then it would be a good idea to post a message to the
> linux-kernel list describing the problem, how to reproduce it, and offer
> them access to the data file.

Well, this was on 2.4.2.  I'm building 2.4.6 right now to see if the
problem goes away.  The version of mount I'm using is mount-2.10f.

While I'm at it, I might finally be able to coax the USB drivers into
working nicely with my hardware and my Handspring Visor.  Whoo.  This
is living on the edge, for a Debian Potato user.  Nevermind the fact
that the other distros have been doing USB for a while now...

--
Chris Riddoch         |  epistemological  | Send spam to: uce at ftc.gov
socket at peakpeak.com   |  humility         |