[Xenomai] Issues with Xenomai 3.0.5...

Philippe Gerum rpm at xenomai.org
Tue Jun 6 09:41:52 CEST 2017


On 06/06/2017 04:12 AM, Jim Langston wrote:
> Philippe,
> 
> That worked well, thank you!
> 
> Now that my test applications are running, I wanted to be sure that
> everything was kosher.  If I run 'latency' or 'switchtest' and press
> CTRL+C to stop them, I get a seg fault.

Receiving SIGSEGV/SIGBUS/SIGILL is 100% abnormal. Can you send the stack
backtrace of such fault over gdb?

  Otherwise they seem to run
> normally, basically the same as my old 2.X Xenomai systems.
> 
> *gdb latency*
> 
> Thread 4 "sampling-1035" received signal SIGXCPU, CPU time limit exceeded.

This is a watchdog trigger (CONFIG_XENO_OPT_WATCHDOG) after 4s spent
running purely real-time stuff without leaving any cycles to the regular
kernel, which denotes a problem. On x86, the default real-time sampling
period for latency testing is 100 us, which may be a bit too fast for a
Geode LX. You may want to try latency -p 200 or higher.

Also, you should make sure to turn off any time consuming debug option
in kernel space, e.g. DEBUG_VM, DEBUG_LIST, XENO_OPT_DEBUG_LOCKING,
IPIPE_TRACE etc.

For actual latency testing, disabling debug in the user-space support
(--disable-debug) is better too, since this option has some overhead,
except --enable-debug=symbols, which only adds -g to the compilation
flags but keeps the optimizer enabled (-O2).

> 
> #0  0xb770c25d in __cobalt_read (fd=3, buf=0xb74373a8, nbyte=8) at
> rtdm.c:180
> #1  0x08049e60 in latency (cookie=0x0) at latency.c:165
> #2  0xb770d760 in cobalt_thread_trampoline (p=0xbfff47bc) at thread.c:166
> #3  0xb76bc5bc in start_thread () from /lib/libc.so.0
> #4  0xb7678ded in clone () from /lib/libc.so.0*
> 
> *
> *gdb switchtest
> *
> Thread 18 "rtuo_ufps-20" received signal SIG32, Real-time event 32.
> 
> #0  0xb7729f42 in do_ioctl (fd=fd at entry=3,
> request=request at entry=2148009525,
>     arg=arg at entry=0xb718d358) at rtdm.c:132
> #1  0xb772a204 in __cobalt_ioctl (fd=3, request=2148009525) at rtdm.c:167
> #2  0x0804b1a5 in rtuo (cookie=0x97bec30) at switchtest.c:654
> #3  0xb772b760 in cobalt_thread_trampoline (p=0xbfb88afc) at thread.c:166
> #4  0xb76da5bc in start_thread () from /lib/libc.so.0
> #5  0xb7696ded in clone () from /lib/libc.so.0*
> 
> *
> Is this normal, or do I need to do some more digging through my build
> environment?
> 

I can make sense of a Cobalt-based application receiving SIGXCPU and
SIGWINCH from the real-time core for internal purposes, but I don't have
any explanation for SIGRTMIN at the moment.

-- 
Philippe.



More information about the Xenomai mailing list