1. 27 10月, 2008 1 次提交
    • S
      trace: fix printk warning for u64 · e2862c94
      Stephen Rothwell 提交于
      A powerpc ppc64_defconfig build produces these warnings:
      
      kernel/trace/ring_buffer.c: In function 'rb_add_time_stamp':
      kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'u64'
      kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'u64'
      kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'u64'
      
      Just cast the u64s to unsigned long long like we do everywhere else.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e2862c94
  2. 24 10月, 2008 1 次提交
    • I
      ftrace: warning in kernel/trace/ftrace.c · f17845e5
      Ingo Molnar 提交于
      this warning:
      
        kernel/trace/ftrace.c:189: warning: ‘frozen_record_count’ defined but not used
      
      triggers because frozen_record_count is only used in the KCONFIG_MARKERS
      case. Move the variable it there.
      
      Alas, this frozen-record facility seems to have little use. The
      frozen_record_count variable is not used by anything, nor the flags.
      
      So this section might need a bit of dead-code-removal care as well.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f17845e5
  3. 23 10月, 2008 7 次提交
  4. 22 10月, 2008 2 次提交
  5. 21 10月, 2008 5 次提交
    • S
      ftrace: stack tracer only record when on stack · 81520a1b
      Steven Rostedt 提交于
      The stack trace API does not record if the stack is not on the current
      task's stack. That is, if the stack is the interrupt stack or NMI stack,
      the output does not show. Also, the size of those stacks are not
      consistent with the size of the thread stack, this makes the calculation
      of the stack size usually bogus.
      
      This all confuses the stack tracer. I unfortunately do not have time to
      fix all these problems, but this patch does record the worst stack when
      the stack pointer is on the tasks stack (instead of bogus numbers).
      
      The patch simply returns if the stack pointer is not on the task's stack.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      81520a1b
    • S
      ftrace: rename the ftrace tracer to function · 3ce83aea
      Steven Rostedt 提交于
      To avoid further confusion between the ftrace infrastructure and the
      function tracer. This patch renames the "ftrace" function tracer
      to "function".
      
      Now in available_tracers, instead of "ftrace" there will be "function".
      
      This makes more sense, since people will not know exactly what the
      "ftrace" tracer does.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3ce83aea
    • S
      ftrace: rename FTRACE to FUNCTION_TRACER · 606576ce
      Steven Rostedt 提交于
      Due to confusion between the ftrace infrastructure and the gcc profiling
      tracer "ftrace", this patch renames the config options from FTRACE to
      FUNCTION_TRACER.  The other two names that are offspring from FTRACE
      DYNAMIC_FTRACE and FTRACE_MCOUNT_RECORD will stay the same.
      
      This patch was generated mostly by script, and partially by hand.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      606576ce
    • S
      ftrace: fix depends · c2db8054
      Steven Rostedt 提交于
      A lot of tracers have HAVE_FTRACE as a dependent config where it
      really should not. The HAVE_FTRACE is a misnomer (soon to be fixed)
      and describes if the architecture has the function tracer (mcount)
      implemented. The ftrace infrastructure is implemented in all archs.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c2db8054
    • S
      ftrace: release functions from hash · bd95b88d
      Steven Rostedt 提交于
      The x86 architecture uses a static recording of mcount caller locations
      and is not affected by this patch.
      
      For architectures still using the dynamic ftrace daemon, this patch is
      critical. It removes the race between the recording of a function that
      calls mcount, the unloading of a module, and the ftrace daemon updating
      the call sites.
      
      This patch adds the releasing of the hash functions that the daemon uses
      to update the mcount call sites. When a module is unloaded, not only
      are the replaced call site table update, but now so is the hash recorded
      functions that the ftrace daemon will use.
      
      Again, architectures that implement MCOUNT_RECORD are not affected by
      this (which currently only x86 has).
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bd95b88d
  6. 14 10月, 2008 24 次提交