On Wed, 2007-04-11 at 18:10 +0800, Zhao Forrest wrote: > On 4/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-04-11 at 02:53 -0700, Paul Jackson wrote: > > > I'm confused - which end of ths stack is up? > > > > > > cpuset_exit doesn't call do_exit, rather it's the other > > > way around. But put_files_struct doesn't call do_exit, > > > rather do_exit calls __exit_files calls put_files_struct. > > > > I'm guessing its x86_64 which generates crap traces. > > > Yes, it's x86_64. Is there a reliable way to generate stack traces under > x86_64? > Can enabling "[ ] Compile the kernel with frame pointers" help?
Sometimes, the best is to redo the undo of the dwarf based stack unwinder. But as you said, that _huge_ number of buffers might be the issue, I'm looking through the codepaths from __blkdev_put on downwards, I suspect we hold a single lock somewhere,... So hold on with patching the unwinder back in (unless of course you fancy doing so :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
