1. 22 1月, 2009 4 次提交
    • S
      trace: separate out rt tasks from wakeup tracer · 3244351c
      Steven Rostedt 提交于
      Impact: add option to trace all tasks or just RT tasks
      
      The current wakeup tracer only traces RT task wakeups. This is
      fine for those interested in wake up timings of RT tasks, but
      it is useless for those that are interested in the causes
      of long wakeups for non RT tasks.
      
      This patch creates a "wakeup_rt" to implement the tracing of just
      RT tasks (as the current "wakeup" does). And makes "wakeup" now
      trace all tasks as an average developer would expect.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3244351c
    • S
      ring-buffer: do not swap if recording is disabled · 97b17efe
      Steven Rostedt 提交于
      If the ring buffer recording has been disabled. Do not let
      swapping of ring buffers occur. Simply return -EAGAIN.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      97b17efe
    • S
      trace: do not disable wake up tracer on output of trace · 5bc4564b
      Steven Rostedt 提交于
      Impact: fix to erased trace output
      
      To try not to have the outputing of a trace interfere with the wakeup
      tracer, it would disable tracing while the output was printing. But
      if a trace had started when it was disabled, it can show a partial
      trace. To try to solve this, on closing of the tracer, it would
      clear the trace buffer.
      
      The latency tracers (wakeup and irqsoff) have two buffers. One for
      recording and one for holding the max trace that is printed. The
      clearing of the trace above should only affect the recording buffer.
      But for some reason it would move the erased trace to the print
      buffer. Probably due to a race with the closing of the trace and
      the saving ofhe max race.
      
      The above is all pretty useless, and if the user does not want the
      printing of the trace to be traced itself, then the user can manual
      disable tracing. This patch removes all the code that tries to keep
      the output of the tracer from modifying the trace.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5bc4564b
    • I
      Merge branch 'tracing/ftrace' into tracing/core · 03b30d15
      Ingo Molnar 提交于
      03b30d15
  2. 20 1月, 2009 7 次提交
  3. 19 1月, 2009 2 次提交
    • S
      ftrace: test for running of recordmcount.pl twice on an object · b43f7093
      Steven Rostedt 提交于
      Impact: fix failure of dynamic function tracer selftest
      
      In a course of development, a developer does several makes on their
      kernel. Sometimes, the make might do something abnormal. In the
      case of running the recordmcount.pl script on an object twice,
      the script will duplicate all the calls to mcount in the __mcount_loc
      section.
      
      On boot up, the dynamic function tracer is careful when it modifies
      code, and performs several consistency checks. One is to not modify
      the call site if it is not what it expects it to be. If a function
      call site is listed twice, the first entry will convert the site
      to a nop, and the second will fail because it expected to see a
      call to mcount, but instead it sees a nop. Thus, the function tracer
      is disabled.
      
      Eric Sesterhenn reported seeing:
      
      [    1.055440] ftrace: converting mcount calls to 0f 1f 44 00 00
      [    1.055568] ftrace: allocating 29418 entries in 116 pages
      [    1.061000] ------------[ cut here ]------------
      [    1.061000] WARNING: at kernel/trace/ftrace.c:441
      
       [...]
      
      [    1.060000] ---[ end trace 4eaa2a86a8e2da23 ]---
      [    1.060000] ftrace failed to modify [<c0118072>] check_corruption+0x3/0x2d
      [    1.060000]  actual: 0f:1f:44:00:00
      
      This warning shows that check_corruption+0x3 already had a nop in
      its place (0x0f1f440000). After compiling another kernel the problem
      went away.
      
      Later Eric Paris notice the same type of issue. Luckily, he saved
      the vmlinux file that caused it. In the file we found a bunch of
      duplicate mcount call site records, which lead us to the script.
      
      Perhaps this problem only happens to people named Eric.
      
      This patch changes the script to test if the __mcount_loc already
      exists in the object file, and if it does, it will print out
      an error message and kill the compile.
      Reported-by: NEric Sesterhenn <snakebyte@gmx.de>
      Reported-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b43f7093
    • I
  4. 17 1月, 2009 26 次提交
  5. 16 1月, 2009 1 次提交