Re: [tracing, hang] dumping events gets stuck in synchronise_sched

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2010-08-18 at 08:40 +1000, Dave Chinner wrote:

> > When the systems locks up, I assume you want to see why? The trace_pipe
> > should show that without locking the system.
> 
> Exactly.

So it did work?

> 
> > You could also try downloading trace-cmd and running the tracer with
> > that. That will save all traces to a file while running the trace.
> 
> I don't have tens of GB available to store all the traces that an
> xfstests test run generates. In general, I don't need the traces,
> either, and when  I do the problem is usually in the current ring
> buffer, which is why I typically dump the events after the fact.

Note, you can also use: trace-cmd extract

which will extract the data from the ring buffer after the fact.

The resulting file ("trace.dat" by default) would allow you to read it
via kernelshark, or use the trace-cmd filters on it as well.

> 
> If the trace file cannot be made to handle this type of use
> robustly, then perhaps it should be removed...

You mean because it uses synchronize_sched() it should be removed? Seems
that it was another kernel bug that caused the issue.

I find the trace file nice to use, to look at a file over and over
again. I could just cat trace_pipe into another file and look at that
too I suppose. But I don't find this reason as rational to remove it.

-- Steve