> On 09/22/2014 12:25 PM, [email protected] wrote: >>> On 09/19/2014 06:53 PM, Philippe Gerum wrote: >>>> On 09/19/2014 06:11 PM, [email protected] wrote: >>>>> Hello everyone, >>>>> I'm currently working with Xenomai in my company's project using >>>>> RTNet >>>>> as >>>>> realtime ethernet driver to communicate with Elmo card via EtherCAT >>>>> protocol and SOEM as master library. >>>>> >>>>> I'm using Linux 3.8.13 patched with Xenomai 2.6.3. >>>>> >>>>> I'm debugging a simple test which is a cycle of send & receive data >>>>> with a >>>>> frequency of 1 kHz. The test runs fine for a quite long time (30 mins >>>>> in >>>>> average), but still throws runaway thread after a certain time. >>>>> >>>>> My loop is a periodic thread: >>>>> >>>>> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000); >>>>> while(1){ >>>>> rt_task_wait_period(); >>>>> ec_send_processdata(); //SOEM function >>>>> ec_receive_processdata(); //SOEM function >>>>> } >>>>> >>>>> With SIGDEBUG & gdb, the error seems to start from clock_gettime >>>>> (when >>>>> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to >>>>> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I >>>>> heard >>>>> that the High Resolution Timer of Linux kernel is not supported for >>>>> processor 64 bits, this could be the reason for such behavior? >>>>> >>>> >>>> I never heard about the restriction you are referring to. >>>> >>> >>> If you are referring to the deadlock issue when calling the regular >>> glibc services such as gettimeofday/clock_gettime from rt mode, then >>> this is not a 64bit specific issue. You need to call the >>> clock_gettime() >>> service from the Xenomai POSIX API, asking for CLOCK_HOST_REALTIME. >>> >>> -- >>> Philippe. >>> >> >> Hello, >> I tried to call clock_gettime() with CLOCK_HOST_REALTIME, but my >> hardware >> fall directly into error. If I understand correctly, CLOCK_HOST_REALTIME >> is called from the POSIX skin, a.k.a secondary mode, > > The POSIX skin does not imply secondary mode, quite the contrary: it > aims at running POSIX services in primary mode. Secondary mode means > regular linux mode, not controlled by the Xenomai co-kernel. > > while my application > > No, it runs from primary mode. It has been designed with that intent in > mind, precisely because the way gettimeofday/clock_gettime are > implemented over the vsyscall mechanism makes them incompatible with any > usage from primary mode. > >> need to run at primary mode, that's why it stops running right away. >> Using >> CLOCK_MONOTONIC & CLOCK_REALTIME was fine. What is the main difference >> between these timers? > > CLOCK_REALTIME served by the POSIX skin uses the Xenomai idea of time > (epoch). This is not in sync with the epoch used by the regular kernel, > hence HOST_REALTIME. CLOCK_MONOTONIC served by the POSIX skin is the > same as rt_timer_tsc(), i.e. a raw tick count maintained by some high > precision timer we use on the hardware platform, monotonically increasing. > > You should really make sure to use the right clock_gettime(), i.e. the > one from libpthread_rt. > http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/ > > -- > Philippe. >
Thanks Philippe, I'm following the porting guide that you suggest. One small question: Is this possible to mix between POSIX & native skin of Xenomai? Because most of my app's code is in native skin, but some services are only accessible via POSIX skins (like setschedparam). Is there a risk in mixing these 2? And which are the flags need to be passing to the compiler to get a good mixes? Huy Cong VU Ps: Same question but with a new thread, like Gilles advice _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
