2009/6/1 Felix Blyakher <felixb@xxxxxxx>: > > On Jun 1, 2009, at 12:38 PM, Alexander Beregalov wrote: > >> It was Gentoo's `emerge --metadata`. It reads many small files (ebuilds). >> I am sure it cannot be easily reproduced. > > Right. Otherwise many more people would've reported it. > >> It runs fine everyday. I do not have a testcase. >> I can try to run it forever in loop if you need. > > Yes, that will be good. > The problem is that the traces are confusing. From one > side readdir stack makes sense based on your description > of the load, but OTOH the panic is from xfs_bmapi(), which > doesn't fit in that backtrace at all. It seems like > backtrace is from the concurrently running different thread. > Don't have good idea for this bug atm. The host is still running, SysRq-W shows two precesses with the same stacktraces. SysRq : Show Blocked State task PC stack pid father emerge D 0000000000000000 3856 8399 8387 ffff880078da7b48 0000000000000046 ffff8800074b4b40 ffff880078da7af4 0000000000000001 000000000000d948 00000000001d2000 0000000000000001 ffff8800074b4b40 ffff88007f4725a0 ffff8800074b4eb8 0000000100000246 Call Trace: [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff806d707d>] __mutex_lock_common+0x16d/0x4f0 [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff80280eb0>] ? trace_hardirqs_on+0x20/0x40 [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff806d7528>] mutex_lock_nested+0x48/0x70 [<ffffffff802e7328>] do_lookup+0xd8/0x270 [<ffffffff802e7776>] __link_path_walk+0x2b6/0xf00 [<ffffffff802e884c>] ? do_path_lookup+0xec/0x200 [<ffffffff802e884c>] ? do_path_lookup+0xec/0x200 [<ffffffff802e863e>] path_walk+0x7e/0x100 [<ffffffff802e8816>] do_path_lookup+0xb6/0x200 [<ffffffff802e9bd8>] do_filp_open+0xf8/0x9e0 [<ffffffff802f6199>] ? alloc_fd+0x49/0x170 [<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80 [<ffffffff802f6289>] ? alloc_fd+0x139/0x170 [<ffffffff802d7f6b>] do_sys_open+0x9b/0x130 [<ffffffff802d806e>] sys_open+0x2e/0x50 [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b emerge D 0000000000000000 3280 1643 1901 ffff88000f43bb48 0000000000000046 ffff88002dc33870 ffff88000f43baf4 0000000000000001 000000000000d948 00000000001d2000 0000000000000003 ffff88002dc33870 ffff88007ea30000 ffff88002dc33be8 0000000300000246 Call Trace: [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff806d707d>] __mutex_lock_common+0x16d/0x4f0 [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff80280eb0>] ? trace_hardirqs_on+0x20/0x40 [<ffffffff802e7328>] ? do_lookup+0xd8/0x270 [<ffffffff806d7528>] mutex_lock_nested+0x48/0x70 [<ffffffff802e7328>] do_lookup+0xd8/0x270 [<ffffffff802e7776>] __link_path_walk+0x2b6/0xf00 [<ffffffff802e884c>] ? do_path_lookup+0xec/0x200 [<ffffffff802e884c>] ? do_path_lookup+0xec/0x200 [<ffffffff802e863e>] path_walk+0x7e/0x100 [<ffffffff802e8816>] do_path_lookup+0xb6/0x200 [<ffffffff802e9bd8>] do_filp_open+0xf8/0x9e0 [<ffffffff802f6199>] ? alloc_fd+0x49/0x170 [<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80 [<ffffffff802f6289>] ? alloc_fd+0x139/0x170 [<ffffffff802d7f6b>] do_sys_open+0x9b/0x130 [<ffffffff802d806e>] sys_open+0x2e/0x50 [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b I will try to reproduce it. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
