All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: Wladislav Wiebe <wladislav.kw@gmail.com>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: Makefile: workaround printk recursion bug
Date: Wed, 10 Apr 2013 09:37:42 -0700	[thread overview]
Message-ID: <51659556.3070502@gmail.com> (raw)
In-Reply-To: <51652CF5.1080009@gmail.com>

On 04/10/2013 02:12 AM, Wladislav Wiebe wrote:
>
> From: Wladislav Wiebe <wladislav.kw@gmail.com>
>
> Function tracing is broken due to removal of selecting FRAME_POINTER with
> FUNCTION_TRACER as result of commit: b732d439cb43336cd6d7e804ecb2c81193ef63b0
>
> Latest commit ad8c396936e328f5344e1881afde9e28d5f2045f "MIPS: Unbreak
> function tracer for 64-bit kernel." fixes just the early startup hang,
> but on MIPS64/CAVIUM_OCTEON2 are still random printk recursion bugs
> which cause also Kernel hangs, especially on late startup phase when
> network drivers get loaded. This patch enable for CAVIUM_OCTEON2/64 Bit
> architecture -fno-omit-frame-pointer cflag when FUNCTION_TRACER get
> enabled. This will fix random Kernel hangs with "BUG: recent printk
> recursion!" from linux/kernel/printk.c.
>
> Maybe there exist a other solution in mcount handling, since in the
> commit message from Al Cooper is mentioned that "MIPS frame pointers are
> generally considered to be useless because they cannot be used to unwind
> the stack. Unfortunately the MIPS function tracing code has bugs that
> are masked by the use of frame pointers. This commit fixes the bugs so
> that MIPS frame pointers don't need to be enabled."
>
> But this is just a solution for MIPS32 - on a symmetric multiprocessing
> @MIPS64/CAVIUM_OCTEON2 it doesn't work properly.

There are a couple of problems that I see with this patch:

1) It doesn't handle non-OCTEON2.  Surely other 64-bit targets are 
effected as well

2) You don't say how it is broken or how this fixes it.

3) Function graph tracing on 3.9.0-rc6 compiled with gcc-4.7.0 works 
fine for me without this.  So I see no need to clog up the make files 
with a rats nest of ifdef

Without more information about why this  is needed, I would have to say NAK.

David Daney

>
> Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
> ---
>   arch/mips/Makefile |    9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 6f7978f..8befe31 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -119,6 +119,15 @@ cflags-$(CONFIG_SB1XXX_CORELIS)	+= $(call cc-option,-mno-sched-prolog) \
>   				   -fno-omit-frame-pointer
>
>   #
> +# FTrace depended compiler options, currently only needed by MIPS64/OCTEON2.
> +#
> +ifdef CONFIG_64BIT
> +ifdef CONFIG_CAVIUM_OCTEON2
> +cflags-$(CONFIG_FUNCTION_TRACER) += $(call cc-option,-fno-omit-frame-pointer)
> +endif
> +endif
> +
> +#
>   # CPU-dependent compiler/assembler options for optimization.
>   #
>   cflags-$(CONFIG_CPU_R3000)	+= -march=r3000
>

  reply	other threads:[~2013-04-10 16:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10  9:12 [PATCH] MIPS: Makefile: workaround printk recursion bug Wladislav Wiebe
2013-04-10 16:37 ` David Daney [this message]
2013-04-11  7:46   ` Wladislav Wiebe

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=51659556.3070502@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=wladislav.kw@gmail.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.