Messages in this thread |  | | | Subject | Re: [tracing, hang] dumping events gets stuck in synchronise_sched | | From | Steven Rostedt <> | | Date | Tue, 17 Aug 2010 19:07:11 -0400 |
| |
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
|  |