Re: 2.6.24-rc7-rt2 [PATCH] latency tracer fix for ppc32

[Luotao Fu <l.fu@pengutronix.de>]

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

Hi Steve,

I found out that the tracer got stuck on ppc32 platforms because some early
functions call _mcount before mcount_enabled is initialized at all. I made a
patch, which marks these functions as notrace to solve this problem. With this
patch I can successfully boot up our mpc5200b platform and make latency trace.
(tested with -b switch in cyclictest). Please comment.

I made my patch against the -rt2 tree since the dummy call early_printk() in
-rt3 conflicts with our implementation of a functional early_printk(). It
should also work with -rt3 though.

cheers
Luotao Fu
-- 
   Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de


[-- Attachment #1.2: ppc32_notrace_init_functions.diff --]
[-- Type: text/x-diff, Size: 2726 bytes --]

Subject: don't trace early init functions for ppc32
By: Luotao Fu <l.fu@pengutronix.de>
  If the latency tracer is turned on in the kernel config, _mcount calls are
  added automatically to every function call during compiling since -pg
  compiling flag is set. _mcount() checks first the variable mcount_enabled.
  (see implementation of _mcount() in arch/powerpc/kernel/entry_32.S) This will
  stuck forever if _mcount is called before mcount_enabled is initialized. Hence
  we mark some init functions as notrace, so that _mcount calls are not added to
  these functions.

Signed-off-by: Luotao Fu <l.fu@pengutronix.de>

---
 arch/powerpc/kernel/cputable.c |    4 ++--
 arch/powerpc/kernel/io.c       |    2 +-
 arch/powerpc/kernel/setup_32.c |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

Index: arch/powerpc/kernel/cputable.c
===================================================================
--- arch/powerpc/kernel/cputable.c.orig
+++ arch/powerpc/kernel/cputable.c
@@ -1333,7 +1333,7 @@ static struct cpu_spec __initdata cpu_sp
 
 static struct cpu_spec the_cpu_spec;
 
-struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
+notrace struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
 {
 	struct cpu_spec *s = cpu_specs;
 	struct cpu_spec *t = &the_cpu_spec;
@@ -1380,7 +1380,7 @@ struct cpu_spec * __init identify_cpu(un
 	return NULL;
 }
 
-void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
+notrace void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
 {
 	struct fixup_entry {
 		unsigned long	mask;
Index: arch/powerpc/kernel/io.c
===================================================================
--- arch/powerpc/kernel/io.c.orig
+++ arch/powerpc/kernel/io.c
@@ -120,7 +120,7 @@ EXPORT_SYMBOL(_outsl_ns);
 
 #define IO_CHECK_ALIGN(v,a) ((((unsigned long)(v)) & ((a) - 1)) == 0)
 
-void _memset_io(volatile void __iomem *addr, int c, unsigned long n)
+notrace void _memset_io(volatile void __iomem *addr, int c, unsigned long n)
 {
 	void *p = (void __force *)addr;
 	u32 lc = c;
Index: arch/powerpc/kernel/setup_32.c
===================================================================
--- arch/powerpc/kernel/setup_32.c.orig
+++ arch/powerpc/kernel/setup_32.c
@@ -88,7 +88,7 @@ int ucache_bsize;
  * from the address that it was linked at, so we must use RELOC/PTRRELOC
  * to access static data (including strings).  -- paulus
  */
-unsigned long __init early_init(unsigned long dt_ptr)
+notrace unsigned long __init early_init(unsigned long dt_ptr)
 {
 	unsigned long offset = reloc_offset();
 	struct cpu_spec *spec;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]