Hi all,

maybe someone of you could help me with the following issue of forge/cobalt 
(it seems complicated, I hope I will make sense):

A queue test of freertos reproducibly causes a freeze in the following
situation:

a thread has apparently both XNRELAX and XNWEAK set.

syncobj_lock() is called, i.e. 
  cobalt_monitor_enter() -> sc_cobalt_monitor_enter

syncobj_wait_grant(); is called, i.e. 
  cobalt_monitor_wait()
      -> sc_cobalt_monitor_wait/cobalt_monitor_wait() in kernel mode
              info = xnsynch_sleep_on(); seems to be interrupted (opret = 
-EINTR)
              cobalt_monitor_enter_inner() also seems to return (ret = -EINTR)
      -> if -EINTR in userspace call cobalt_monitor_wait() <=== this seems to 
block indefinitely

This is where the application reliably freezes... To summarize what happens 
in cobalt_monitor_wait it in words:

* cobalt_monitor_wait() is called with mon->gate locked
* the lock is unlocked via xnsynch_release();
* xnsynch_sleep_on(synch, timeout, tmode), which should wait for an event 
  on my queue is interrupted and returns XNBREAK.
* cobalt_monitor_enter_inner also return -EINTR.
* cobalt_monitor_wait() is left without mon->gate locked
* back in user space, cobalt_monitor_wait() calls cobalt_monitor_enter() 
  when getting -EINTR, which will retry as long as possible to lock 
  the object.
* cobalt_monitor_enter() goes into kernel space to lock the object and 
  never returns.

On thing I do not understand is:

in kernel cobalt_monitor_wait(), the synch object is unlocked via
xnsynch_release(). What happens if this synchobj was locked via 
mon->gate.fastlock ? Shouldnt that also be released?

What other reason could there be if the synch object was released 
via xnsynch_release, xnsynch_acquire was interrupted for 
xnsynch_release to block?

Thanks in advance for helping me on this,
Matthias

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to