On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel even if no cobalt thread is running, only a
rt_igb and the rtnet stack.
OK, that was already my idea as well.
That rcu_irq_enter_irqson must not be there. Trying to understand right
now how it can sneak in. What are your RCU configs?
Found it.
Preconditions: CONFIG_PREEMPT_NONE/VOLUNTARY -> CONFIG_TREE_RCU
Now switch_mm_irqs_off, which we also use for primary tasks, carries
some trace_tlb_flush_rcuidle. The "_rcuidle" appendix makes the
difference. Such tracepoints end up in tracepoint.h's __DO_TRACE in the
rcuidle path that contains a rcu_irq_enter_irqson of this form:
void rcu_irq_exit_irqson(void)
{
unsigned long flags;
local_irq_save(flags);
rcu_irq_exit();
local_irq_restore(flags);
}
And those local_irq* bite us. With CONFIG_TINY_RCU, rcu_irq_exit_irqson
is empty.
I guess we need to skip the problematic tracepoints, either when I-pipe
is on or when the caller is in the primary domain.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
