Re: [Xenomai] Fwd: Re: Problem that the Linux scheduler is not called for some ms

[Philippe Gerum <rpm@xenomai.org>]

On 10/07/2015 04:23 PM, Harald Feßl wrote:
> Am 07.10.2015 um 11:07 schrieb Philippe Gerum:
>> On 10/07/2015 11:01 AM, Johann Obermayr wrote:
>>> Am 05.10.2015 um 13:54 schrieb Philippe Gerum:
>>>> On 10/05/2015 12:53 PM, Johann Obermayr wrote:
>>>>> Am 29.09.2015 um 17:56 schrieb Philippe Gerum:
>>>>>> On 09/29/2015 02:38 PM, Johann Obermayr wrote:
>>>>>>> Am 25.09.2015 um 10:44 schrieb Harald Feßl:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have done a ipipe trace for some working and one non working
>>>>>>>> cycle.
>>>>>>>> The trace is stopped after the non working cycle.
>>>>>>>> I have marked the working cycles with green and the non working
>>>>>>>> cycle
>>>>>>>> with red in my graphical trace.
>>>>>>>> The ipipe trace and graphical trace are stopped at the same time.
>>>>>>>>
>>>>>>>> After the non working cycle the system is working correct again for
>>>>>>>> some seconds or minutes.
>>>>>>>>
>>>>>>>> I think the problem is, that the migration of the task "cyclic"
>>>>>>>> from
>>>>>>>> xenomai to linux, needs sometimes some ms.
>>>>>>>>
>>>>>>>> Harald
>>>>>>>>
>>>>>>>> Harald Fessl
>>>>>>>> Betriebssystem
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> SIGMATEK GmbH & Co KG
>>>>>>>> Sigmatekstraße 1
>>>>>>>> 5112 Lamprechtshausen
>>>>>>>> Österreich / Austria
>>>>>>>>
>>>>>>>> Tel.:  +43/6274/4321-0
>>>>>>>> Fax:  +43/6274/4321-18
>>>>>>>> E-Mail: harald.fessl@sigmatek.at
>>>>>>>> http://www.sigmatek-automation.com
>>>>>>>>
>>>>>>>> ***********************Please
>>>>>>>> note:************************************
>>>>>>>> This email and all attachments are confidential and intended
>>>>>>>> solely for
>>>>>>>> the person or entity to whom it is addressed. If you are not the
>>>>>>>> named
>>>>>>>> addressee you must not make this email and all attachments
>>>>>>>> accessible
>>>>>>>> to any other person. If you have received this email in error
>>>>>>>> please
>>>>>>>> delete it together with all attachments.
>>>>>>>> ***********************************************************************
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 23.09.2015 um 12:36 schrieb Jan Kiszka:
>>>>>>>>> On 2015-09-23 10:51, Harald Feßl wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> The linux tasks are not blocked (not all).
>>>>>>>>>> I think the problem is , that the linux scheduler function in the
>>>>>>>>>> kernel
>>>>>>>>>> is not called for some ms.
>>>>>>>>>> I have also traced the calls to the scheduler function
>>>>>>>>>> "static int __sched __schedule(void)"
>>>>>>>>>> and sometimes when the decribed problem occur this function is
>>>>>>>>>> not
>>>>>>>>>> called while no linux task are running.
>>>>>>>>> If no task is runnable, there is also no reason to invoke
>>>>>>>>> schedule.
>>>>>>>>>
>>>>>>>>> Please post a ftrace log of your system, covering both a working
>>>>>>>>> and a
>>>>>>>>> non-working cycle, including cobalt* and at least sched and irq
>>>>>>>>> events.
>>>>>>>>>
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>> Hello Philippe and Xenomai forum,
>>>>>>>
>>>>>>> we have some trouble with a xenomai task (cyclic with prio 30) after
>>>>>>> switching to secondary domain.
>>>>>>> Linux ARM 3.0, Xenomai 2.6.2.1, and CONFIG_XENO_OPT_PRIOCPL=y.
>>>>>> PRIOCPL should be disabled, and all tests redone in this context.
>>>>>>
>>>>> Hello,
>>>>>
>>>>> the result is the same.
>>>>> Some time your cyclic task will not schedule after switching to
>>>>> secondary domain.
>>>>>
>>>> I just noticed you were using 2.6.2.1. Several bugs in the domain
>>>> switch
>>>> mechanism have been fixed since then until 2.6.4, and the latter still
>>>> suffers a recently SMP rescheduling issue already fixed in the 2.6.x
>>>> maintenance branch.
>>>>
>>>> You should try running your code on top of that branch before diving
>>>> any
>>>> deeper, I suspect you might be facing a bug that has been fixed
>>>> already.
>>>>
>>> Hello,
>>>
>>> we have test it with Linux 3.10.53 (Freescale) and Xenomai 2.6.4.
>>> But we see the same problem.
>>>
>> Ok, so please send a trace freeze with that configuration illustrating
>> the problem, with PRIOCPL disabled. The previous traces you sent include
>> RPI noise, which makes their interpretation uncertain.
>>
> 
> Hello Philippe
> 
> I am working with Johann at the same problem.
> We don't know what you mean with RPI noise.
> Is there a kernel switch to turn of some trace records.


I mean the traces generated by the PRIOCPL option. This one needs to be
disabled.


-- 
Philippe.