Re: rt_task_wait_period hangs system
Paolo Mantegazza <[email protected]> Thu, 15 Mar 2018 14:44:09 +0100
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4910815264129911393== Content-Type: multipart/alternative; boundary="------------1B56443FB950643645898651" Content-Language: en-US This is a multi-part message in MIME format. --------------1B56443FB950643645898651 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I know, very well, that bugs can be everywhere, but It is hard, for me,=20 to believe that rt_task_wait_period does not work. Are you sure that the start time and period are OK? In any case there is an alternative to see if it is the real culprit. It=20 is the one I use in my applications, as making a task periodic is, for=20 me again, just a long standing compatibility call. For such an alternative, no make periodic and wait period, assuming you=20 have the "period" in internal count units, do: - define "RT_TIME until;" - just before you periodic loop set "until =3D rt_get_time();" - in place of "rt_task_wait_period" use "rt_sleep_until(until +=3D period= );" As a further idea I suggest you to lowe your pririty to 1 and install=20 the RTAI watchdog support. Is it not that the troubles, yours or mine, are in usiing COMEDI? Let us know. Paolo On 03/15/2018 12:46 PM, Paul Pfeiffer wrote: > Dear RTAI community, > > after installation of RTAI 5.1 and running the latency tests, I am=20 > trying to run production code, which leads to a system crash.=20 > Debgugging lead me to conclude that it is the call to=20 > rt_task_wait_period, that produced the crash. > > System info: > RTAi 5.1, Kernel 4.9.76, Intel i5-6600K > > In detail, the call happens in a custom kernel mtask_wait_period does=20 > not work.odule, that first chooses between oneshot and periodic mode=20 > (both lead to the same crash) > > ``` > #ifdef ONESHOT_MODE > =C2=A0 rt_set_oneshot_mode(); > =C2=A0 start_rt_timer(1); > #else > =C2=A0 rt_set_periodic_mode(); > =C2=A0 #endif > > ``` > > =C2=A0registers a real time task > > ``` > rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* declare i= f we use the FPU */ > > retVal =3D rt_task_init( &dynClampTask.rtTask, dynclamp_loop, dummy,=20 > stackSize, priority, usesFPU, signal ); > ``` > > and then makes it periodic > > ``` > rt_task_make_periodic( &dynClampTask.rtTask, rt_get_time() +=20 > periodTicks, periodTicks ) > ``` > Both of this calls are successful. > > In the task dynclamp_loop, the only calls to RTAI are > ``` > rt_get_cpu_time_in_ns() > ``` > which poses no problem and > > ``` > rt_task_wait_period() > ``` > which kills the system.=C2=A0 This has worked in previous RTAI versions= and=20 > on other machines, so we were wondering whether this a 5.1 specific=20 > problem or related to our new machine? For completeness, I attach the=20 > source code of the kernel module, the functions of interest are=20 > dynclamp_loop, init_dynclamp_loop and cleanup_dynclamp_loop. Any ideas? > > Maybe related, I have recently been reporting my diffuculties=20 > installing RTAI 5.1, especially the system hig up when rtai_sched was=20 > loaded. Thanks to the help of Paolo, see thread "RTAI in debian 9",=20 > this problem was fixed via manual generation of a calibration file. > > Sorry, for the long question, but we are really eager to use the=20 > latest RTAI version and would like to understand this problem. > > Best, Paul > > > > > _______________________________________________ > Rtai mailing list > [email protected] > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai --------------1B56443FB950643645898651 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf= -8"> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> <div class=3D"moz-cite-prefix">I know, very well, that bugs can be everywhere, but It is hard, for me, to believe that rt_task_wait_period does not work.<br> Are you sure that the start time and period are OK?<br> <br> In any case there is an alternative to see if it is the real culprit. It is the one I use in my applications, as making a task periodic is, for me again, just a long standing compatibility call.<br> <br> For such an alternative, no make periodic and wait period, assuming you have the "period" in internal count units, do:<br> - define "RT_TIME until;"<br> - just before you periodic loop set "until =3D rt_get_time();"<br> - in place of "rt_task_wait_period" use "rt_sleep_until(until +=3D period);"<br> <br> As a further idea I suggest you to lowe your pririty to 1 and install the RTAI watchdog support.=C2=A0 <br> <br> Is it not that the troubles, yours or mine, are in usiing COMEDI?<b= r> <br> Let us know.<br> <br> Paolo<br> <br> <br> On 03/15/2018 12:46 PM, Paul Pfeiffer wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]">Dear RTAI community, <br> <br> after installation of RTAI 5.1 and running the latency tests, I am trying to run production code, which leads to a system crash. Debgugging lead me to conclude that it is the call to rt_task_wait_period, that produced the crash. <br> <br> System info: <br> RTAi 5.1, Kernel 4.9.76, Intel i5-6600K <br> <br> In detail, the call happens in a custom kernel mtask_wait_period does not work.odule, that first chooses between oneshot and periodic mode (both lead to the same crash) <br> <br> ``` <br> #ifdef ONESHOT_MODE <br> =C2=A0 rt_set_oneshot_mode(); <br> =C2=A0 start_rt_timer(1); <br> #else <br> =C2=A0 rt_set_periodic_mode(); <br> =C2=A0 #endif <br> <br> ``` <br> <br> =C2=A0registers a real time task <br> <br> ``` <br> rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* decla= re if we use the FPU */ <br> <br> retVal =3D rt_task_init( &dynClampTask.rtTask, dynclamp_loop, dummy, stackSize, priority, usesFPU, signal ); <br> ``` <br> <br> and then makes it periodic <br> <br> ``` <br> rt_task_make_periodic( &dynClampTask.rtTask, rt_get_time() + periodTicks, periodTicks ) <br> ``` <br> Both of this calls are successful. <br> <br> In the task dynclamp_loop, the only calls to RTAI are <br> ``` <br> rt_get_cpu_time_in_ns() <br> ``` <br> which poses no problem and <br> <br> ``` <br> rt_task_wait_period() <br> ``` <br> which kills the system.=C2=A0 This has worked in previous RTAI vers= ions and on other machines, so we were wondering whether this a 5.1 specific problem or related to our new machine? For completeness, I attach the source code of the kernel module, the functions of interest are dynclamp_loop, init_dynclamp_loop and cleanup_dynclamp_loop. Any ideas? <br> <br> Maybe related, I have recently been reporting my diffuculties installing RTAI 5.1, especially the system hig up when rtai_sched was loaded. Thanks to the help of Paolo, see thread "RTAI in debian 9", this problem was fixed via manual generation of a calibration file. <br> <br> Sorry, for the long question, but we are really eager to use the latest RTAI version and would like to understand this problem. <br> <br> Best, Paul <br> <br> <br> <br> <fieldset class=3D"mimeAttachmentHeader"></fieldset> <br> <pre wrap=3D"">_______________________________________________ Rtai mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]">Rtai@= rtai.org</a> <a class=3D"moz-txt-link-freetext" href=3D"https://mail.rtai.org/cgi-bin/= mailman/listinfo/rtai">https://mail.rtai.org/cgi-bin/mailman/listinfo/rta= i</a></pre> </blockquote> <p><br> </p> </body> </html> --------------1B56443FB950643645898651-- --===============4910815264129911393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rtai mailing list [email protected] https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai --===============4910815264129911393==--