On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote:

On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote:

quoted

On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:

quoted

On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:

quoted

What compiler version are you using? Does the behaviour change if you
use a newer/older compiler? It sounds to me like there's some deeper bug
and your patch is just papering over it.

I tried with gcc 4.3.2. Let me try with a recent version and update.

quoted

Agreed, this doesn't make any sense. Try changing the compiler version to see if
the problem goes away or stops.  It might also be worthwhile to dump the
contents of the device tree at the start and end of the kexec process.  If the
changing of how a function is inlined is causing a hang, its likely changing how
the putprops function is writing information to the device tree.  Understanding
what that change is will likely provide clues to how the code has changed.

Neil, there was no code change in fs2dt.c

Sure there was, by modifying the code to tell it to not inline the putprops
function, you changed how the complier optimizes that code block.  There may not
be any source level code change, but the assembly is certainly different, and it
must be so in a way thats causing a hang.  The putpops function changes the
contents of the ppc64 device-tree, so if this is a compiler bug, and its causing
a hang, I imagine we'll see some manifestation in a change in the device tree
contents.

As I mentioned in the patch description, when I retained the variable dt_len
and dt_len = dt assignment, kexec/kdump kernel would work. But even if I
comment the "dt_len = dt" assignment kernel would hang. If you need I can
send objdump of fs2dt.o with and without this assignment.

Regards,
M. Mohan Kumar.