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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
