On 03/01/2013 09:54 AM, Petr Cervenka wrote:
> SOLVED (perhaps)
>
>>
>>> Hello.
>>>
>>> I have a problem with a mutex shared by 3 real-time user tasks.
>>> Once in a while (~hours) the mutex get locked with the first task
>>> as owner and the other two tasks are fronzen on rt_mutex_aquire
>>> calls. But I have double checked, that every "acquire" of that
>>> mutex is followed by "release".
>>>
>>> Typical example: Lets call those tasks REG, SEND, RECEIVE
>>>
>>> RECV: acquire RECV: release
>>>
>>> RECV: acquire RECV: release
>>>
>>> RECV: acquire - FREEZE
>>>
>>> REG: acquire REG: release
>>>
>>> REG: acquire REG: release
>>>
>>> REG: acquire REG: release
>>>
>>> SEND: acquire - FREEZE
>>>
>>> There are also other threads, sync. objects, network sockets, ...
>>> in the system, but the threads are frozen by this particular
>>> mutex. rt_task_unblock call unblocks the tasks, return value of
>>> rt_mutex_acquire is -4 (-EINTR), as expected. Used version of
>>> Xenomai 2.5.6, skin native. Was there any known issue similar to
>>> that behavior? Also it seems that rt_mutex_create is called
>>> before mlockall call? Could it be a problem?
>>
>>
>> It is a bit old to recall. Could you try and reproduce the problem
>> with 2.6.2.1 ?
>>
>
> I tried to use new version of everything (kernel 3.5.7, xenomai
> 2.6.2.1, ...) and I got some exception to the kernel log in
> rt_mutex_create. So I suppose that the problem was caused by calling
> of rt_mutex_create before mlockall. I already fixed it and now I'm
> waiting for some longer term results. I for now it seems to be
> SOLVED. If not, I will let you know. Thank you for your support.
It is not expected to get a crash, though, will try and see if I can
reproduce the problem.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
