Hi. Using Latencytop 0.5 on a p4 with either kernels 2.6.39 or 2.6.39.1 gives the following oops: ------------[ cut here ]------------ WARNING: at kernel/trace/trace.c:2725 tracing_ctrl_write+0x114/0x123() Pid: 1797, comm: latencytop Not tainted 2.6.39 #2 Call Trace: [<c10338d4>] warn_slowpath_common+0x67/0x8e [<c108df49>] ? tracing_ctrl_write+0x114/0x123 [<c108df49>] ? tracing_ctrl_write+0x114/0x123 [<c1033977>] warn_slowpath_fmt+0x2e/0x30 [<c108df49>] tracing_ctrl_write+0x114/0x123 [<c10d61b1>] ? rw_verify_area+0x5d/0x101 [<c10d6574>] vfs_write+0x8c/0x14f [<c108de35>] ? tracing_release+0x73/0x73 [<c10d66e5>] sys_write+0x3d/0x6b [<c1590e93>] sysenter_do_call+0x12/0x22 [<c158007b>] ? tg3_get_invariants+0xd0/0x209c [<c1580000>] ? tg3_get_invariants+0x55/0x209c ---[ end trace 6f3260379750d0f0 ]--- ~ Andy Ref: https://lkml.org/lkml/2011/6/14/277
It's not an oops, it's a WARN_ONCE(fmt) and I'm disappointed that WARN_ONCE does not include the text of fmt within the 'cut here'. If you go to trace.c:2725 you will see: /* Only need to warn if this is used to change the state */ WARN_ONCE(1, "tracing_enabled is deprecated. Use tracing_on"); Why is latency_top monkeying around with ftrace stuff anyway? It is suppose to be using perf syscalls. "tracing_enabled" will go away completely in the future. Don't use it.
Many thanks for taking the time to clarify this for me (I should have looked at things more closely). I agree entirely with you, though, that having the fmt text inside the cut-here block would be quite helpful. Is there any value in keeping this report open so others can react to or address the points you make?
There was at one point a patch somewhere which changed the ----- cut here ---- marker into ------ trace begin, please include the message above ---- or something like that... but i think it wasn't merged as to not break tools parsing this stuff... :|
*** This bug has been marked as a duplicate of bug 38132 ***