On 18.04.2013 11:11, Stanislav Meduna wrote: > from a new log that includes syscall tracing it seems that a thread > waiting in a timerfd is woken, but does not return from the read: For the record, the problem seems to be the issue that the http://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v3.4-rt&id=52cecaa fixed in v3.4.38-rt52 (tracing: Fix free of probe entry by calling call_rcu_sched()). A kernel with just this commit reverted stalled once per ~4 hours, with this one it did not stall in ~24h (I will surely try to run it longer). Why did is always manifest itself by hanging in return from timerfd read (and not e.g. when timer_create and friends were used) is beyond me, but there will be a reason. Sorry for the false alarm, it was already fixed at the time I reported it - it is just that one wants to know the reason before updating to a brand new kernel with 750+ other changes. A general question: I am seeing a few recent changes in the tracing code. Is it generally safe to have at least latency histogram enabled in the production code, or is it advised not to compile these features in? I'd like to see the latencies the customer is getting in the real environment, but if the code is considered as work-in-progress, it is better to play it safe. Thanks -- Stano -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
