Fwd: Debugging system freeze, SIGXCPU
arimozes at neocisinc.com
Mon Feb 25 17:57:05 CET 2019
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 :-)
On Mon, Feb 25, 2019 at 11:08 AM Philippe Gerum <rpm at xenomai.org> 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
> 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:
Staff Software Engineer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More information about the Xenomai