Re: More details on health monitoring notifications

[Philippe Gerum <rpm@xenomai.org>]

Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
> Correct, it is running on x86. I am not sure what would be causing a page 
>
> fault in the EVL threads as I figured the mlockall call by evl_init would take 
>
> care of preventing that from happening.
>

We may have a clue by knowing which type of memory is being referred
to.

- Did you trace the offending access using gdb, is it regular memory?

- Does your application fork() in any way prior to running into this
  issue?

>  
>
> I have tried to run the app with gdb (used to work fine pre-EVL), but now I 
>

Which previous environment was this? Xenomai 3.x + I-pipe?

> get all sorts off exceptions and error codes when trying to run in the 
>
> debugger. I quite frequently see EPERM issues with evl mutex unlock/lock (even 
>
> though it works fine when not run through a debugger). Also, when I swap the 
>
> thread mode flag from T_HMOBS to T_HMSIG and run in the debugger, I get a 
>
> "11776 CPU time limit exceeded (core dumped)" error on the create call for an 
>
> evl event in one of my threads.
> I am not sure why I am seeing such different 
>
> behavior in the debugger versus the normal run when it comes to the evl API 
>
> calls. Any ideas?
>

SIGXCPU is an alias of SIGDEBUG, the signal the EVL core uses to warn
you about something wrong in general. e.g. if CONFIG_EVL_DEBUG_WOLI is
set in the kernel configuration and the application is doing something
wrong wrt mutex-based locking patterns, the core would notify it using
SIGDEBUG. The causes are described for the T_WOLI bit at [1]. The core
might also issue SIGDEBUG when the watchdog triggers for the current
thread (CONFIG_EVL_WATCHDOG).

[1] https://evlproject.org/core/user-api/thread/#health-monitoring

-- 
Philippe.