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

[Dave Chinner]

On Tue, Aug 17, 2010 at 07:07:11PM -0400, Steven Rostedt wrote:
> 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?

I haven't got back to the hanging kernel yet - I had to go back to
2.6.35 to triage and test a regression (which I couldn't with broken
writeback) and I'm still dealing with the fallout of that one...

> > 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.

Right now I'm using the trace file for exactly what the docuemntation
says it should be used for, but it hangs. You're saying that the
interface is effectively redundant because there's a trace_pipe
interface that shouldn't hang and I should use that instead.

Debug interfaces should be reliable in the face of common problems -
a system burning a CPU in a tight loop is a pretty common problem.
That leads to three options: either fix the hang, document the fact
that the trace file is not reliable and that you should use other
interfaces, or remove the interface altogether.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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/