From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum References: <6f55db98-0988-3b9f-f1dc-6f393211af4d@xenomai.org> <1062b417-12fd-9eda-83bf-ab7c1eda4548@xenomai.org> Message-ID: Date: Wed, 7 Jun 2017 07:29:59 +0200 MIME-Version: 1.0 In-Reply-To: <1062b417-12fd-9eda-83bf-ab7c1eda4548@xenomai.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Issues with Xenomai 3.0.5... List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jlangston@panurgyinc.com Cc: xenomai@xenomai.org On 06/06/2017 09:41 AM, Philippe Gerum wrote: > 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@entry=3, >> request=request@entry=2148009525, >> arg=arg@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. > SIGRTMIN is used by the NPTL library internally for implementing pthread_cancel(), gdb notices this signal received by the debuggee. The backtrace above does not reflect a segfault, this is only a report about receiving SIGRTMIN. Passing "handle 32 pass noprint nostop" to gdb prior to running the app would disable such reporting, and would not prompt the user for acting upon it either. -- Philippe.