second "mount" hangs

Si spse at
Mon Nov 19 20:54:14 EST 2001

> I think that the last time I saw this reported, it was also on a blkmtd
> device. A quick perusal of the blkmtd code shows that it uses sleep_on
> functions - which makes me instantly assume it's racy.
> Simon - can you reproduce this problem?
> --
> dwmw2

This is reproducible on both blkmtd and mtdram (and probably others) - this
is from stock 2.4.14
testbox:/home/spse# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "mtdram test device"

testbox:/home/spse/src/mtd/util# ./mkfs.jffs2 >/dev/mtd/0
testbox:/home/spse/src/mtd/util# mount -t jffs2 /dev/mtdblock/0 /mnt/test
testbox:/home/spse/src/mtd/util# umount /mnt/test
testbox:/home/spse/src/mtd/util# mount -t jffs2 /dev/mtdblock/0 /mnt/test
testbox:/home/spse/src/mtd/util# mount -t jffs2 /dev/mtdblock/0 /mnt/test

a ksymoops of a alt-sysrq T gives:
Trace; c0232f55 <rwsem_down_read_failed+f5/118>
Trace; c0235739 <stext_lock+789/31c6>
Trace; c013de29 <sync_inodes+15/4c>
Trace; c012ebc3 <fsync_dev+17/30>
Trace; c013e427 <invalidate_device+17/58>
Trace; c01cabce <mtdblock_release+22/b0>
Trace; c0132e36 <blkdev_put+66/ac>
Trace; c0131bcf <get_sb_bdev+1b7/2ec>
Trace; c013fa23 <set_devname+27/54>
Trace; c01321ab <do_kern_mount+af/13c>
Trace; c0140755 <do_add_mount+21/cc>
Trace; c01409db <do_mount+13f/158>
Trace; c014084d <copy_mount_options+4d/9c>
Trace; c0140a78 <sys_mount+84/c4>
Trace; c0106b0b <system_call+33/38>

so possibly there is something in mtdblock that is going wrong.


More information about the linux-mtd mailing list