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>