Re: Tracing/ftrace: trouble with trace_entries and trace_pipe

[Frédéric Weisbecker]

2008/9/16 Pekka Paalanen <pq@xxxxxx>:
> Ok, so the problem is probably the commit I mentioned. It makes the
> no_tracer tracer to set tracer_enabled to 0, and I can't find where
> it would be set to 1 for mmiotrace. And this interferes with
> tracing_read_pipe(), making it quit when iter->pos is non-zero.
> See no_trace_init() in trace.c. According to this, the cat-quit
> occurs when the buffer gets empty after first data, but this isn't
> totally in agreement with what I recall from my experiments. And it
> does happen also on other times than injecting markers.
>
> So either it is wrong to check tracer_enabled in tracing_read_pipe(),
> or no_trace_init() should not touch it.

Indeed that could be the problem.
None_tracer is chosen as the default tracer when the tracer engine
loads. But actually no_trace_init is not called at this time.

But if you set another tracer and reset current_tracer to none, you
will call no_trace_init. Since tracer_enabled is not reset to 1 with
other tracer's init functions, the problem occurs when you choose one
more time another tracer.

I think that mmiotrace receives a smaller flow of entries (depends on
the debugged module) whereas sched_switch or function's tracer, as an
example, are continuously fed and never enter the "while
(trace_empty(iter))" block. That's why I only see this bug in
mmiotrace.

Perhaps it would be a good idea to reenable tracer_enabled on
tracing_set_trace_write() just before calling the init callback of the
tracer chosen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/