On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote: > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote: > > On Wed, Jun 17, 2009 at 10:40:07AM -0400, Neil Horman wrote: > > > > > > send objdump of fs2dt.o with and without this assignment. > > > > > > > That would be a fine thing to do, and I'd be happy to compare them. My though > > > regarding the comparison of the device tree on a good and bad run was meant to > > > expidite what change in the assembly we'd be looking for. If its the kdump > > > kernel boot thats hanging, Its likely hanging on something in the device tree, > > > as thats whats being manipulated by this code. So I figure that understanding > > > whats changed there will point us toward what change in the assembly might be > > > responsible for the hang. The assmebly's going to be signficantly different > > > (lots of optimization might be lost from no longer inlining a function), so > > > anything that helps us narrow down whats changed will be good > > > > I am attaching the objdumps of fs2dt with and without dt_len. > > > Well it definately looks like removing that variable had some code changes. > It'll take some time to match it up to source, but Most interesting I think is > the variance in putprops around address f34. Looks like its doing some string > maniuplation in a reversed order, using a huge offset. Might be worthwhile to > check to see if theres any string overruns in this code. Yeah I still suspect it's just a bug in the code that's being exposed now. Mohan, can you try running it under valgrind? cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090624/83773575/attachment.bin>
