On Tue, Apr 14, 2009 at 07:06:58AM -0500, dkg_004 at verizon.net
wrote:>kjournald D C0284784 0 408 6 (L-TLB)
>[<c0284240>] (schedule+0x0/0x64c) from [<c00f8724>]
(journal_commit_transaction+0x16c/0x1568)
>[<c00f85b8>] (journal_commit_transaction+0x0/0x1568) from
[<c00fd99c>] (kjournald+0xbc/0x260)
>[<c00fd8e0>] (kjournald+0x0/0x260) from [<c0070d9c>]
(kthread+0xe8/0x128)
>[<c0070cb4>] (kthread+0x0/0x128) from [<c005d980>]
(do_exit+0x0/0x8c8)
Are you using any other patches or modifications to the kernel? It
looks like the journal_commit_transaction() is blocked waiting for
some transaction to finish:
while (commit_transaction->t_updates) {
DEFINE_WAIT(wait);
prepare_to_wait(&journal->j_wait_updates, &wait,
TASK_UNINTERRUPTIBLE);
if (commit_transaction->t_updates) {
spin_unlock(&commit_transaction->t_handle_lock);
spin_unlock(&journal->j_state_lock);
schedule(); <------------
spin_lock(&journal->j_state_lock);
spin_lock(&commit_transaction->t_handle_lock);
}
finish_wait(&journal->j_wait_updates, &wait);
}
This can happen if the kernel has OOPS'ed while in the middle of an
ext3 operation, or if there is some bug in ext3. The 2.6.21 kernel is
quite old, so there are one or two bug fixes that might possibly apply
to your problem. So the first easy thing to tryy would be to upgrade
to the latest kernel (2.6.29) and see if that fixes your problem.
You might also check your logs to see if there were any OOPS messages
before the system locked up.
And, I would try compiling with LOCKDEP enabled to see if that shows
the problem.
- Ted