second "mount" hangs

second "mount" hangs

[Michael Rothwell]

Hi,

I mounted a JFFS2 filesystem stored on a 16MB partition on a zip disk,
using mtdblock and blktmd. I accidentally typed "mount /mnt/flash"
rather than "umount /mnt/flash", and "mount" is now hung. Unkillable.
/mnt/flash is still mounted and usable, but not unmountable. It seems I
will have to reboot to umount the filesystem. I can't even eject the zip
disk.

-Michael

Re: second "mount" hangs

[David Woodhouse]

rothwell@holly-springs.nc.us said:
> I mounted a JFFS2 filesystem stored on a 16MB partition on a zip disk,
> using mtdblock and blktmd. I accidentally typed "mount /mnt/flash"
> rather than "umount /mnt/flash", and "mount" is now hung. Unkillable. /
> mnt/flash is still mounted and usable, but not unmountable. It seems I
> will have to reboot to umount the filesystem. I can't even eject the
> zip disk. 

ISTR someone reported this to me recently. I don't recall them ever 
responding with the results of SysRq-T when I asked though. What are the 
relevant processes waiting for?


--
dwmw2

Re: second "mount" hangs

[Michael Rothwell]

Well, SysRQ-t prints "SysRQ : Show State" and that's it. Strangely.

-M

On Sun, 2001-11-18 at 13:33, David Woodhouse wrote:
> 
> 
> rothwell@holly-springs.nc.us said:
> > I mounted a JFFS2 filesystem stored on a 16MB partition on a zip disk,
> > using mtdblock and blktmd. I accidentally typed "mount /mnt/flash"
> > rather than "umount /mnt/flash", and "mount" is now hung. Unkillable. /
> > mnt/flash is still mounted and usable, but not unmountable. It seems I
> > will have to reboot to umount the filesystem. I can't even eject the
> > zip disk. 
> 
> ISTR someone reported this to me recently. I don't recall them ever 
> responding with the results of SysRq-T when I asked though. What are the 
> relevant processes waiting for?
> 
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

NAND test hardwhere?

[Charles Manning]

Hi

Plz pardon the pun - it's getting late in the year.

I wonder if anyone has a good idea where to scrounge out -even $buy$ - NAND 
test hardware.

I want to fiddle around with NAND chips or SmartMedia, not DOC - preferably 
ISA card or parallel port or some such so that I can plug it into a PC and 
access simply.

I have tried contacting Samsung to no avail (their www says they have ISA and 
EPP [parallel port] dev boards) but they are not answering emails.

If I can't find something I might just have to hack up something from an old 
ISA card and a SmartMedia card.

Any info much appreciated.

Thanx

-- Charles

Re: NAND test hardwhere?

[David Woodhouse]

manningc@actrix.gen.nz said:
>  If I can't find something I might just have to hack up something from
> an old  ISA card and a SmartMedia card. 

The DiskOnChip has fairly easily accessible NAND flash, and comes with 
convenient ISA eval boards.

--
dwmw2

Re: second "mount" hangs

[Michael Rothwell]

Here ya go (SysRQ-t):

Nov 18 13:49:54 gromit kernel: mount         D C0D62000     0 18486  
1131                     (NOTLB)
Nov 18 13:49:54 gromit kernel: Call Trace: [__down_read+88/120]
[get_super+73/100] [sync_inodes+21/76] [fsync_dev+23/48]
[invalidate_device+23/88] 
Nov 18 13:49:54 gromit kernel: Call Trace: [<c028ca8c>] [<c013253d>]
[<c013f659>] [<c012f5ef>] [<c013fc77>] 
Nov 18 13:49:54 gromit kernel:    [<d48ea72e>] [blkdev_put+99/144]
[get_sb_bdev+360/672] [<d497ab80>] [set_devname+39/84]
[do_kern_mount+170/296] 
Nov 18 13:49:54 gromit kernel:    [<d48ea72e>] [<c0133cfb>] [<c0132ae8>]
[<d497ab80>] [<c0141307>] [<c013309a>] 
Nov 18 13:49:54 gromit kernel:    [<d497ab80>] [do_add_mount+28/208]
[do_mount+270/296] [copy_mount_options+80/156] [sys_mount+124/192]
[system_call+51/56] 
Nov 18 13:49:54 gromit kernel:    [<d497ab80>] [<c0142098>] [<c01422f6>]
[<c014219c>] [<c014238c>] [<c0106beb>] 


On Sun, 2001-11-18 at 13:33, David Woodhouse wrote:
> 
> 
> rothwell@holly-springs.nc.us said:
> > I mounted a JFFS2 filesystem stored on a 16MB partition on a zip disk,
> > using mtdblock and blktmd. I accidentally typed "mount /mnt/flash"
> > rather than "umount /mnt/flash", and "mount" is now hung. Unkillable. /
> > mnt/flash is still mounted and usable, but not unmountable. It seems I
> > will have to reboot to umount the filesystem. I can't even eject the
> > zip disk. 
> 
> ISTR someone reported this to me recently. I don't recall them ever 
> responding with the results of SysRq-T when I asked though. What are the 
> relevant processes waiting for?
> 
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: second "mount" hangs

[David Woodhouse]

rothwell@holly-springs.nc.us said:
> Here ya go (SysRQ-t):

Thanks. I have seen this before - didn't reach any useful conclusions so 
far. That has to be the down_read(s->s_umount) in get_super(). I don't know 
why anything would have the write lock on that though. Can you show the 
backtraces for all the other current processes too? 

--
dwmw2

Re: second "mount" hangs

[David Woodhouse]

rothwell@holly-springs.nc.us said:
>  I mounted a JFFS2 filesystem stored on a 16MB partition on a zip
> disk, using mtdblock and blktmd. I accidentally typed "mount /mnt/
> flash" rather than "umount /mnt/flash", and "mount" is now hung.
> Unkillable. /mnt/flash is still mounted and usable, but not
> unmountable. It seems I will have to reboot to umount the filesystem.
> I can't even eject the zip disk.

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

Re: second "mount" hangs

[Si]

>
> 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
[Hang]

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.

cheers
si

Re: second "mount" hangs

[Russ Dill]

On Mon, 2001-11-19 at 18:54, Si wrote:
> >
> > 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
> [Hang]
> 
> 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.
> 

I've seen similar problems with busybox mount for some time (post
2.4.7ish) if the below entry is in /etc/fstab when busybox mount -a is
run, a similar hang occurs:

/dev/mtdblock2  /               jffs2   rw              0       0

both mount and kupdated are stuck in D states (this is on
2.4.15-pre6-rmk1)

Proc;  kupdated
>>EIP; c0021cbc <schedule+2a4/428>   <=====
Trace; c0021a18 <schedule+0/428>
Trace; c0145930 <__down_read+84/a0>
Trace; c01458ac <__down_read+0/a0>
Trace; c0049bac <sync_supers+f0/19c>
Trace; c0049abc <sync_supers+0/19c>
Trace; c00491f8 <sync_old_buffers+18/88>
Trace; c00491e0 <sync_old_buffers+0/88>
Trace; c0049598 <kupdate+140/150>
Trace; c0049458 <kupdate+0/150>
Trace; c001ac24 <kernel_thread+38/44>
Proc;  mount
>>EIP; c0021cbc <schedule+2a4/428>   <=====
Trace; c0021a18 <schedule+0/428>
Trace; c0145930 <__down_read+84/a0>
Trace; c01458ac <__down_read+0/a0>
Trace; c0049ccc <get_super+74/98>
Trace; c0049c58 <get_super+0/98>
Trace; c0059e9c <sync_inodes+1c/58>
Trace; c0059e80 <sync_inodes+0/58>
Trace; c0046150 <fsync_dev+28/40>
Trace; c0046128 <fsync_dev+0/40>
Trace; c005a694 <invalidate_device+24/68>
Trace; c005a670 <invalidate_device+0/68>
Trace; c00cb56c <mtdblock_release+28/114>
Trace; c00cb544 <mtdblock_release+0/114>
Trace; c004bb08 <blkdev_put+a0/128>
Trace; c004ba68 <blkdev_put+0/128>
Trace; c004a330 <get_sb_bdev+198/314>
Trace; c004a198 <get_sb_bdev+0/314>
Trace; c004aad4 <do_kern_mount+d4/1a4>
Trace; c004aa00 <do_kern_mount+0/1a4>
Trace; c005d5f0 <do_add_mount+28/14c>
Trace; c005d5c8 <do_add_mount+0/14c>
Trace; c005d93c <do_mount+150/164>
Trace; c005d7ec <do_mount+0/164>
Trace; c005d9ec <sys_mount+9c/e4>
Trace; c005d950 <sys_mount+0/e4>
Trace; c0019840 <ret_fast_syscall+0/38>

Re: second "mount" hangs

[David Woodhouse]

spse@secret.org.uk said:
>  This is reproducible on both blkmtd and mtdram (and probably others)
> - this is from stock 2.4.14

You're right - sorry for the misplaced blame. Fixed in v1.50 of mtdblock.c.

--
dwmw2