All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: mohan@in.ibm.com
Cc: linuxppc-dev@ozlabs.org, Simon Horman <horms@verge.net.au>,
	kexec@lists.infradead.org, miltonm@bga.com
Subject: Re: [PATCH] Do not inline putprops function
Date: Wed, 17 Jun 2009 22:26:35 +1000	[thread overview]
Message-ID: <1245241595.4269.15.camel@concordia> (raw)
In-Reply-To: <20090617115917.GD31595@in.ibm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1182 bytes --]

On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote:
> Do not inline putprops function
> 
> With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
> kexec -l and kexec -p respectively). This happened after the patch "ppc64:
> cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
> reverting each hunk and then found out that retaining following lines in
> fs2dt.c makes kexec/kdump work.
> 
> -static unsigned *dt_len; /* changed len of modified cmdline
> -                           in flat device-tree */
> 
> [....]
> 
> -               dt_len = dt;
> 
> I don't have any clue why removing a unused variable would cause the kexec
> kernel to hang. After further investigation, I observed that if the putprops
> function is not inlined, kexec/kdump kernel would work even after removing
> the above lines.
> 
> This patch directs gcc to not inline the putprops function. Now we could
> invoke kexec and kdump kernels.

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.

cheers

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: mohan@in.ibm.com
Cc: linuxppc-dev@ozlabs.org, Simon Horman <horms@verge.net.au>,
	kexec@lists.infradead.org, miltonm@bga.com
Subject: Re: [PATCH] Do not inline putprops function
Date: Wed, 17 Jun 2009 22:26:35 +1000	[thread overview]
Message-ID: <1245241595.4269.15.camel@concordia> (raw)
In-Reply-To: <20090617115917.GD31595@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote:
> Do not inline putprops function
> 
> With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
> kexec -l and kexec -p respectively). This happened after the patch "ppc64:
> cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
> reverting each hunk and then found out that retaining following lines in
> fs2dt.c makes kexec/kdump work.
> 
> -static unsigned *dt_len; /* changed len of modified cmdline
> -                           in flat device-tree */
> 
> [....]
> 
> -               dt_len = dt;
> 
> I don't have any clue why removing a unused variable would cause the kexec
> kernel to hang. After further investigation, I observed that if the putprops
> function is not inlined, kexec/kdump kernel would work even after removing
> the above lines.
> 
> This patch directs gcc to not inline the putprops function. Now we could
> invoke kexec and kdump kernels.

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.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-06-17 12:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-17 11:34 [PATCH] Do not inline putprops function M. Mohan Kumar
2009-06-17 11:34 ` M. Mohan Kumar
2009-06-17 11:45 ` Simon Horman
2009-06-17 11:45   ` Simon Horman
2009-06-17 11:59   ` M. Mohan Kumar
2009-06-17 11:59     ` M. Mohan Kumar
2009-06-17 12:26     ` Michael Ellerman [this message]
2009-06-17 12:26       ` Michael Ellerman
2009-06-17 13:04       ` Neil Horman
2009-06-17 13:04         ` Neil Horman
2009-06-17 13:34         ` M. Mohan Kumar
2009-06-17 13:34           ` M. Mohan Kumar
2009-06-17 14:05           ` Neil Horman
2009-06-17 14:05             ` Neil Horman
2009-06-17 14:26             ` M. Mohan Kumar
2009-06-17 14:26               ` M. Mohan Kumar
2009-06-17 14:40               ` Neil Horman
2009-06-17 14:40                 ` Neil Horman
2009-06-23 12:55                 ` M. Mohan Kumar
2009-06-23 12:55                   ` M. Mohan Kumar
2009-06-23 13:56                   ` Neil Horman
2009-06-23 13:56                     ` Neil Horman
2009-06-24  0:27                     ` Michael Ellerman
2009-06-24  0:27                       ` Michael Ellerman
2009-08-03  5:49                       ` M. Mohan Kumar
2009-08-03  5:49                         ` M. Mohan Kumar
2009-08-05 16:49                         ` M. Mohan Kumar
2009-08-05 16:49                           ` M. Mohan Kumar
2009-08-06 14:24                           ` Michael Ellerman
2009-08-06 14:24                             ` Michael Ellerman
2009-08-07 14:35                             ` M. Mohan Kumar
2009-08-07 14:35                               ` M. Mohan Kumar
2009-08-07 14:54                               ` M. Mohan Kumar
2009-08-07 14:54                                 ` M. Mohan Kumar
2009-08-10  1:51                                 ` Michael Ellerman
2009-08-10  1:51                                   ` Michael Ellerman
2009-08-10  7:37                           ` Milton Miller
2009-08-10  7:37                             ` Milton Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1245241595.4269.15.camel@concordia \
    --to=michael@ellerman.id.au \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=mohan@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.