Hi, It seems that the dead umount process keeps freezing on the same place according to its call trace: umount D C03F93E0 0 15738 15706 (NOTLB) de3bbd68 00000082 d5c53540 c03f93e0 00000040 00000000 cbbba954 00000012 0003640e a7439200 000f5fe6 d5c53540 d5c53690 de3ba000 d8c7ba4c 00000282 d5c53540 c02ea6e0 d8c7ba54 00000001 d5c53540 c01170c0 d8c7ba54 d8c7ba54 Call Trace: [<c02ea6e0>] __down+0x90/0x110 [<c01170c0>] default_wake_function+0x0/0x20 [<c017c511>] __mark_inode_dirty+0xd1/0x1c0 [<c02ea8ab>] __down_failed+0x7/0xc [<e0d1fda0>] .text.lock.balloc+0x8/0x128 [udf] [<e0d25767>] udf_write_aext+0xf7/0x170 [udf] [<e0d1fbac>] udf_free_blocks+0xcc/0x100 [udf] [<e0d2cda4>] extent_trunc+0x124/0x180 [udf] [<e0d2d025>] udf_discard_prealloc+0x225/0x2e0 [udf] [<e0d21301>] udf_clear_inode+0x41/0x50 [udf] [<c017285e>] clear_inode+0xde/0x120 [<c01728df>] dispose_list+0x3f/0xb0 [<c0172a92>] invalidate_inodes+0x62/0x90 [<c015e9ad>] generic_shutdown_super+0x5d/0x140 [<c015f69d>] kill_block_super+0x2d/0x50 [<c015e84d>] deactivate_super+0x6d/0x90 [<c0175e6f>] sys_umount+0x3f/0xa0 [<c014bc8d>] do_munmap+0x13d/0x180 [<c014bd14>] sys_munmap+0x44/0x70 [<c0175ee7>] sys_oldumount+0x17/0x20 [<c0103263>] syscall_call+0x7/0xb If my memory serves me well, I've seen something very similar on alt +sysreq+T in previous freezes Hope it helps finding out what the hell could happen... Thanks, compi
On Mon, 24 Jan 2005, Attila Body wrote:
It seems that the dead umount process keeps freezing on the same place according to its call trace:
umount D C03F93E0 0 15738 15706 (NOTLB) de3bbd68 00000082 d5c53540 c03f93e0 00000040 00000000 cbbba954 00000012 0003640e a7439200 000f5fe6 d5c53540 d5c53690 de3ba000 d8c7ba4c 00000282 d5c53540 c02ea6e0 d8c7ba54 00000001 d5c53540 c01170c0 d8c7ba54 d8c7ba54 Call Trace: [<c02ea6e0>] __down+0x90/0x110 [<c01170c0>] default_wake_function+0x0/0x20 [<c017c511>] __mark_inode_dirty+0xd1/0x1c0 [<c02ea8ab>] __down_failed+0x7/0xc [<e0d1fda0>] .text.lock.balloc+0x8/0x128 [udf] [<e0d25767>] udf_write_aext+0xf7/0x170 [udf] [<e0d1fbac>] udf_free_blocks+0xcc/0x100 [udf] [<e0d2cda4>] extent_trunc+0x124/0x180 [udf] [<e0d2d025>] udf_discard_prealloc+0x225/0x2e0 [udf] [<e0d21301>] udf_clear_inode+0x41/0x50 [udf] [<c017285e>] clear_inode+0xde/0x120 [<c01728df>] dispose_list+0x3f/0xb0 [<c0172a92>] invalidate_inodes+0x62/0x90 [<c015e9ad>] generic_shutdown_super+0x5d/0x140 [<c015f69d>] kill_block_super+0x2d/0x50 [<c015e84d>] deactivate_super+0x6d/0x90 [<c0175e6f>] sys_umount+0x3f/0xa0 [<c014bc8d>] do_munmap+0x13d/0x180 [<c014bd14>] sys_munmap+0x44/0x70 [<c0175ee7>] sys_oldumount+0x17/0x20 [<c0103263>] syscall_call+0x7/0xb
If my memory serves me well, I've seen something very similar on alt +sysreq+T in previous freezes Hope it helps finding out what the hell could happen...
This shows that the umount command is waiting for file system to flush dirty data to the disc, but doesn't show if the drive is frozen or just writing very slowly. Do you see any activity if you run: watch cat /proc/driver/pktcdvd/pktcdvd0 Writing lots of small files using packet writing is unfortunately very slow. See http://lists.suse.com/archives/packet-writing/2004-Oct/0004.html for more details. -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340
Hi, On Mon, 2005-01-24 at 21:24 +0100, Peter Osterlund wrote:
On Mon, 24 Jan 2005, Attila Body wrote:
I was able to reproduce the case with a loop mounted udf formatted file, so I think it will be the udf driver instead of pktcdvd.ko Next question is: where should I report this now? Thanks, compi
This shows that the umount command is waiting for file system to flush dirty data to the disc, but doesn't show if the drive is frozen or just writing very slowly. Do you see any activity if you run:
watch cat /proc/driver/pktcdvd/pktcdvd0
Writing lots of small files using packet writing is unfortunately very slow. See
http://lists.suse.com/archives/packet-writing/2004-Oct/0004.html
for more details.
participants (2)
-
Attila Body
-
Peter Osterlund