From: Wladislav Wiebe <[email protected]>
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.
Signed-off-by: Wladislav Wiebe <[email protected]>
---
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
--
1.7.9.5
On 04/10/2013 02:12 AM, Wladislav Wiebe wrote:
>
> From: Wladislav Wiebe <[email protected]>
>
> 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 <[email protected]>
> ---
> 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
>
Hi,
On 10/04/13 18:37, David Daney wrote:
> On 04/10/2013 02:12 AM, Wladislav Wiebe wrote:
>>
>> From: Wladislav Wiebe <[email protected]>
>>
>> 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
well, didn't cross checked with gcc-4.7.0 (currently using gcc-4.3).
Will do so and get back if problem still visible.
Thanks!
>
> Without more information about why this is needed, I would have to say NAK.
>
> David Daney
>
>>
>> Signed-off-by: Wladislav Wiebe <[email protected]>
>> ---
>> 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
>>
>