On Thu, Aug 03, 2017 at 05:44:21AM -0700, Paul E. McKenney wrote: [ ... ]
> > > BTW, function_graph tracer is the most invasive of the tracers. It's 4x > > > slower than function tracer. I'm wondering if the tracer isn't the > > > cause, but just slows things down enough to cause a some other race > > > condition that triggers the bug. > > > > Yes, that could be true. > > > > I tried the following scenario: > > > > - cpufreq governor => userspace + max_freq (1.2GHz) > > - function_graph set ==> OK > > > > - cpufreq governor => userspace + min_freq (200MHz) > > - function_graph set ==> RCU stall > > > > Beside that, I realize the board is constantly processing SOF interrupts > > every 124us, so that adds more overhead. > > > > Removing the USB support, thus the associated processing for the SOF > > interrupts, I don't see anymore the RCU stall. > > Looks like Steve called this one! ;-) Yep :) > > Is it the expected behavior to have the system hang after a RCU stall > > raises ? > > No, but if NMI stack traces are enabled and there are any NMI problems, > bad things can happen. In addition, the bulk of output can cause problems > if you have a slow console connection. Ok, thanks. -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
