http://bugs.orocos.org/show_bug.cgi?id=1033

Summary: Orocos deployer-xenomai and rrtlua-xenomai is no fully
functional with Xenomai 2.6
Product: Toolchain
Version: master
Platform: All
OS/Version: Xenomai 2.x
Status: NEW
Severity: critical
Priority: P3
Component: RTT
AssignedTo: orocos-dev [..] ...
ReportedBy: leopold [dot] palomo [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Since Xenomai team releases its 2.6.x version [1], deployer-xenomai and
rttlua-xenomai shows a lot of messages with the signal warn_upon_switch. It's
something about:
"get threads running with SCHED_OTHER scheduling policy to automatically return
to secondary mode after each primary mode only system call"

This issue has been commented in the xenomai ml [1-3] and the orocos ml [4]. I
don't know if it's something about [5].

The question is that the example [4] shows that changing TM_NONBLOCK by
TM_INFINITE remove all this messages. But this change is not obvious, looking
on it's used in orocos it's on rtt/os/xenomai/fosi.h it's used on the
rtos_sem_trywait function and rt_mutex_acquire.

Changing this parameter in the functions mentioned above means that, quoting
the xenomai documentation:

"Passing TM_INFINITE causes the caller to block indefinitely until the mutex is
available. Passing TM_NONBLOCK causes the service to return immediately without
waiting if the mutex is still locked by another task."

I suppose that the TM_NONBLOCK option implies that the task goes in xenomai to
secondary mode, emitting a signal that is not managing by orocos. I don't know
the consequences of changing that in fosi.h. I suppose the we don't want that
behavior (we blocked) but we don't want to have the deployer blocked by a bunch
of messages making it unusable.

Please, could you look this issue?

Thanks,

Leo

------

[1] http://www.xenomai.org/index.php/Xenomai:News#2011-09-04_Xenomai_2.6.0-rc1
[2] http://www.xenomai.org/pipermail/xenomai/2012-December/027160.html
[3] http://www.xenomai.org/pipermail/xenomai/2012-December/027155.html
[4]
http://lists.mech.kuleuven.be/pipermail/orocos-users/2013-January/006477...
[5]
http://www.orocos.org/forum/orocos/orocos-users/orocos-26-xenomai-262-an...