Philippe, Thank you for the information and the URL. I read through the thread, and I agree with comments that it would be helpful to be able to identify/blacklist/etc problematic calls when porting over existing code to a true RT scenario. In our case the original code was written with "RT-like" behavior in mind, but as there is a lot of code already in place, approaches to identify existing problematic calls would be helpful. I will continue to familiarize myself with the nitty-gritty details, but anything that makes the process easier is always welcome :-)
Ari On Mon, Feb 25, 2019 at 11:08 AM Philippe Gerum <[email protected]> wrote: > > On 2/25/19 2:32 PM, Ari Mozes via Xenomai wrote: > > Resending this question with testcase. > > Can someone give the testcase a try to see if it reproduces the problem I > > am seeing? Is more information needed? > > It takes a couple of minutes before I see the issue occur. > > The random lockup is due to std::chrono::high_resolution_clock::now() > invoking the vDSO form of clock_gettime(). > > SIGXCPU aka Xenomai's SIGDEBUG may be sent by the core in various > situations, but since the code does not set the T_WARNSW for any task, > the only explanation is receiving a Xenomai watchdog notification. See > the help information about CONFIG_XENO_OPT_WATCHDOG in your kernel > configuration. > > After a few secs spinning in the vDSO code which may not be called from > real-time context, the Xenomai core pulls the break and sends SIGXCPU to > the offending process, unless the system locks up before the watchdog > could even trigger. > > Solution: use clock_gettime(CLOCK_HOST_REALTIME) instead of > std::chrono::high_resolution_clock::now() for getting timestamps. > > A related discussion is available at this URL: > https://www.xenomai.org/pipermail/xenomai/2018-December/040133.html > > -- > Philippe. -- Ari Mozes Staff Software Engineer Neocis, Inc. Mobile: 781.266.6553 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
