Hi, On Tue 23-03-10 16:11:45, Kailas Joshi wrote: > I have Lock Debugging enables but that didn't give any warnings. > However, when I did echo "w" >/proc/sysrq-trigger after system lockup, > I got the stack trace for locked up process. > > Following are the stack traces of the processes (I suspect) resulting > in total system lockup - <snip> So kjournald is waiting on a page lock and everyone else waits for kjournald to finish committing or for page lock as well. The strange thing is that I don't see anybody who could hold the page lock everyone is waiting on. So I think further debugging should go in this direction - find out on which page do we wait and who is holding it's lock (you'd need to add tracking of page lock owner but that shouldn't be too hard). > I have few questions here. > I guess process named jbd2/sdb1-8 is kjournald thread. But what is Yes. > flush-8:16 process? Is it the kernel thread for periodically writing > dirty pages to disk? Yes. > Is it the case that these threads are running concurrently at certain > time and are trying to get lock on same pages resulting into deadlock? It should not happen - they should always acquire page lock in index-increasing order so that way deadlocks should be avoided... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
