From mboxrd@z Thu Jan 1 00:00:00 1970 References: <5601A1A1.2020506@siemens.com> <560263A0.4080208@sigmatek.at> <56026810.8040300@sigmatek.at> <56028093.6050805@siemens.com> <56050985.2060002@sigmatek.at> <560A8632.3020107@sigmatek.at> <560AB4C7.3050508@xenomai.org> <561256C6.4070508@sigmatek.at> <561264DD.2020803@xenomai.org> <5614DF5C.200@sigmatek.at> <5614E0C7.6000309@xenomai.org> <56152AED.6050407@sigmatek.at> <561539EB.9090301@xenomai.org> <56161B52.1070903@sigmatek.at> From: =?UTF-8?Q?Harald_Fe=c3=9fl?= Message-ID: <561E043C.1020002@sigmatek.at> Date: Wed, 14 Oct 2015 09:29:00 +0200 MIME-Version: 1.0 In-Reply-To: <56161B52.1070903@sigmatek.at> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Subject: Re: [Xenomai] Fwd: Re: Problem that the Linux scheduler is not called for some ms Reply-To: harald.fessl@sigmatek.at List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org, xenomai@xenomai.org Am 08.10.2015 um 09:29 schrieb Harald Feßl: > Am 07.10.2015 um 17:27 schrieb Philippe Gerum: >> 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. > > Ok, attached there is a ipipe trace without PRIOCPL. > The trace was stopped after the "cyclic" task was not called for more > than 3 ms. > The configuration is still the same as Johann has described. > >> > Hello Philippe Have you seen any problems in our ipipe trace, which I sent last week ? Harald