Re: [Xenomai] Xenomai warn_upon_switch

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 06/28/2013 05:35 PM, Peter Soetens wrote:

> On Thu, Jun 27, 2013 at 11:17 AM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 06/27/2013 11:09 AM, Leopold Palomo-Avellaneda wrote:
>>
>>>
>>> AAnd I don't know how to silent (or if is possible) this messages.
>>
>>
>> Try disabling CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX if currently set in your
>> kernel config. If that is still not enough, then you will have to switch off
>> PTHREAD_WARNSW manually, using pthread_set_mode_np(), for each thread which
>> triggers this signal.
>
> Quoting Gilles:
> "The point is that these messages are telling you that there is a bug,
> either in xenomai code (a bug was fixed since xenomai 2.6.2.1 which
> could explain such a behaviour), or in orocos code. When the bug is
> fixed the signal will disappear."
>
> We're having one thread ( main() ) which is modeswitching all the time
> since it's doing user IO using the console, filesystem etc.
>
> I didn't consider this as a bug, and we only enable PTHREAD_WARNSW for
> specific threads, where it does matter.


What would be a problem would be to change scheduling policy from 
SCHED_FIFO to SCHED_OTHER in a section protected by a mutex, you would 
then get the signal when releasing the mutex. In this case, when using 
xenomai 2.6.2.1, you would get a SIGDEBUG with reason 
SIGDEBUG_MIGRATE_PRIOINV reason, after 2.6.2.1 you would get a SIGDEBUG 
with reason SIGDEBUG_RESCNT_IMBALANCE.

This is considered as a bug, because if the mutex is shared with other 
threads using SCHED_FIFO policy, switching from SCHED_FIFO to 
SCHED_OTHER would cause the thread holding the mutex to switch to 
secondary mode, and so potentially cause a priority inversion.

But I think we already discussed this a long time ago on this list.

Anyway, a way to know what happens is to print the reason in the signal 
handler.

-- 
                                                                 Gilles.