lkml.org 
[lkml]   [2008]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tracing and mmiotrace
On Sat, 22 Mar 2008 16:16:48 -0400 (EDT)
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Sat, 22 Mar 2008, Pekka Paalanen wrote:
>
> > First you see my check in __trace_special() trigger, and then NULL
> > pointer dereference BUG at ffffffff80259332 which translates to
> > kernel/trace/trace.c:639 in tracing_generic_entry_update(), line:
> > entry->preempt_count = pc & 0xff;
> > I don't understand why it tries to dereference NULL even when I
> > check for it.
>
> Interesting. I'll have to look into that more on Monday.

I found the culprit.

My code never calls tracing_reset(). If I had enabled
FTRACE_STARTUP_TEST, the selftest code would run tracing_reset().
So I copied stack_reset() from trace_sysprof.c and now recording works.
My bad.

btw. the semantics of verbose iter_ctrl seem inverted from user point
of view. I also noticed that 'trace' file does not consume the data and
'trace_pipe' does consume the data. This is important information for the
user.

I think it would be nice, if iter_ctrl listed only the flags the current
tracer supports. This would also imply, that the tracer is not started
automatically when selected. Most of the flags are not useful for
mmiotrace.


Thanks.

--
Pekka Paalanen
http://www.iki.fi/pq/


\
 
 \ /
  Last update: 2008-03-23 12:05    [W:0.063 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site