On 02/10/2016 07:41 PM, Charles Kiorpes wrote: > Hello, > I am having some difficulty getting two processes to signal each other on > an AM572x EVM. > I have two small sample applications: > > - app1 : creates an event "MYTEST" using rt_event_create(), clears the > event, and then rt_event_wait()s for TM_INFINITE. When the event is > signaled, app1 rt_event_clear()s the event and then loops back to the > rt_event_wait() > > - app2 : binds to the "MYTEST" event, sleeps for one second, > rt_event_signal()s the event, and then loops back to the one second sleep > > I am using the Mercury core, built natively, configured with: > xenomai-3.0.1/configure \ > --with-core=mercury \ > --enable-debug \ > --enable-pshared \ > --disable-registry \ > --enable-smp \ > --enable-condvar-workaround > > I launch both applications in different terminals in this order: > # sudo ./app1 --session="Test" > # sudo ./app2 --session="Test" > > The following behavior results: > - app1 claims to have successfully created the event > - app2 claims to have successfully bound to the event > - app2 loops correctly, signalling the event once per second > - app1 never wakes up from the first rt_event_wait() > > I am running the 4.1.15-ti-rt kernel with full preemption. > > On an x86 virtual machine with a vanilla 4.2.0-27-generic kernel, the > applications perform as expected (app1 wakes up when app2 signals the > event). > > Any advice as to where to look for further debugging would be greatly > appreciated. >
Over Mercury, the event synchronization is based on a common mutex+condvar pair obtained from the underlying *libc basically. The rest of the implementation for this mechanism is shared with the Cobalt side, except the workaround for the PI breakage the glibc suffers, which is Mercury-only. - does omitting --enable-condvar-workaround change the behavior? - does this issue also happen when both threads belong to the same process (i.e. is it a session-based processing issue?) - does the code check for each and every return code, particularly the return status of rt_event_signal()? Attaching your self-contained test case may help finding out where the problem stands. - after enabling the registry (--enable-registry), is the reported event value consistent when looking at /var/run/xenomai/<user>/Test/alchemy/events/<event_name>? Also, you have a test suite available for Alchemy, which can run on either Mercury/Cobalt cores unmodified. There is a test exercising events there. e.g.: $ cd lib/alchemy/testsuite $ make XENO_CONFIG=/your/xenomai/install/bin/xeno-config test NOTE: The "test" rule in the Makefile assumes that the current shell user is sudoer. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://xenomai.org/mailman/listinfo/xenomai
