Re: rt_task_wait_period hangs system
Paolo Mantegazza <[email protected]> Wed, 21 Mar 2018 17:21:10 +0100
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2709783593597090088== Content-Type: multipart/alternative; boundary="------------B36F2BF627E498CCAE64E6DC" Content-Language: en-US This is a multi-part message in MIME format. --------------B36F2BF627E498CCAE64E6DC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable First of all, if you can let me in your system I'm ready to take the=20 burden of trying to understand what is happening. Even if in 20 years of RTAI development-usage I lost my system just=20 three times. Nonetheless it would be better if=C2=A0 such a system can go= =20 ashtray without any trouble for anybody. I do not want to be hold=20 responsible for anything. On your side you must be ready to be flooded by emails (or phone calls)=20 to push the reset switch of your system. I'm a bit curious to see why neither the calibration nor the kernel=20 space latency test are running. The latter is a bit strange indeed,=20 especially in view of the fact that 4.1 is OK. In fact the changes of=20 5.1 should affect user space, mostly. BTW, have you run also the kthread latency test? Let ime know about it=20 too, please. As a final comment I do not share the fact that max latencies in the=20 range of 10-15 (us) are not great. To me they are indeed, to the point=20 that of being a bit too optimistic. Likely taken for short time checks=20 with Linux unloaded. To have them better I usually have to resort to CPU isolation, matched=20 to a few other things I forgot. Paolo. On 03/21/2018 04:21 PM, Jan Benda wrote: > Hi, > > a follow up on Pauls issue: > > I installed rtai-5.1 with the hal-linux-4.4.115-x86-10.patch on=20 > several intel i3, i5 and i7 machines. The results are mixed - some=20 > work out of the box without tweaking (which is really cool) but others=20 > hang up when insmoding rtai_sched - i.e. when it runs the calibration.=20 > Loading rtai_sched with kernel_latency=3D10 user_latency=3D10, as=20 > suggested, works always (no calibration). > > I modified the realtime/bin/rtai-load script such that it loads=20 > rtai_sched without calibration: > > -- rtai-load=C2=A0=C2=A0 2018-03-20 18:32:15.317723122 +0100 > +++ /home/benda/rtai-load=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2018-03-2= 1 15:53:59.619659835 +0100 > @@ -158,7 +158,9 @@ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # one. If the latter fails too, assume t= he feature is built into > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler or not needed. Obviously= , we should _always_ find > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler... > -=C2=A0=C2=A0=C2=A0=C2=A0 if test -r $rtai_moddir/rtai_$mod$modext; the= n > +=C2=A0=C2=A0=C2=A0=C2=A0 if test "x$mod" =3D "sched"; then > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo $insmod $rtai_moddir/= rtai_$mod$modext kernel_latency=3D10=20 > user_latency=3D10 > +=C2=A0=C2=A0=C2=A0=C2=A0 elif test -r $rtai_moddir/rtai_$mod$modext; t= hen > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test $verbose =3D 1 &&= echo "+ $insmod=20 > $rtai_moddir/rtai_$mod$modext" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo $insmod $rtai_mo= ddir/rtai_$mod$modext > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if test $? =3D 0 ; then > > With that I can run all user tests (see latencies* file for test=20 > results (they are not great, but ok for a first shot) and infos on the=20 > machine, config* is the kernel configuration). > > Note that on the same machine we had rtai 4.1 running without problems. > > However, when I run the kern latency test the machine hangs up - not=20 > when insmoding rtai_sched but when executing the periodic task in=20 > kernel space. So comedi is not to blame here. > > Hanging up means the LEDs on the keyboard blink, the computer is=20 > inacessible, and I do not find any hints in the kernel log. > > I assume that the calibration feature in rtai_sched also runs a=20 > periodic task. > > So something goes wrong with the period tasks. > > Any ideas? > > I also could provide access to the machines. > > Best, > Jan > > > > 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 module, that first=20 >> chooses between oneshot and periodic mode (both lead to the same crash= ) >> >> ``` >> #ifdef ONESHOT_MODE >> =C2=A0=C2=A0 rt_set_oneshot_mode(); >> =C2=A0=C2=A0 start_rt_timer(1); >> #else >> =C2=A0=C2=A0 rt_set_periodic_mode(); >> =C2=A0=C2=A0 #endif >> >> ``` >> >> =C2=A0=C2=A0registers a real time task >> >> ``` >> rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* declare = if 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 version= s=20 >> and on other machines, so we were wondering whether this a 5.1=20 >> specific problem or related to our new machine? For completeness, I=20 >> attach the source code of the kernel module, the functions of=20 >> interest are dynclamp_loop, init_dynclamp_loop and=20 >> 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 >> > > > > > _______________________________________________ > Rtai mailing list > [email protected] > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai --------------B36F2BF627E498CCAE64E6DC 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">First of all, if you can let me in you= r system I'm ready to take the burden of trying to understand what is happening.<br> Even if in 20 years of RTAI development-usage I lost my system just three times. Nonetheless it would be better if=C2=A0 such a sy= stem can go ashtray without any trouble for anybody. I do not want to be hold responsible for anything.<br> On your side you must be ready to be flooded by emails (or phone calls) to push the reset switch of your system.<br> <br> I'm a bit curious to see why neither the calibration nor the kernel space latency test are running. The latter is a bit strange indeed, especially in view of the fact that 4.1 is OK. In fact the changes of 5.1 should affect user space, mostly.<br> BTW, have you run also the kthread latency test? Let ime know about it too, please.<br> <br> As a final comment I do not share the fact that max latencies in the range of 10-15 (us) are not great. To me they are indeed, to the point that of being a bit too optimistic. Likely taken for short time checks with Linux unloaded.<br> To have them better I usually have to resort to CPU isolation, matched to a few other things I forgot.<br> <br> Paolo.<br> <br> On 03/21/2018 04:21 PM, Jan Benda wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]">= Hi, <br> <br> a follow up on Pauls issue: <br> <br> I installed rtai-5.1 with the hal-linux-4.4.115-x86-10.patch on several intel i3, i5 and i7 machines. The results are mixed - some work out of the box without tweaking (which is really cool) but others hang up when insmoding rtai_sched - i.e. when it runs the calibration. Loading rtai_sched with kernel_latency=3D10 user_latency=3D10, as suggested, works always (no calibration). <br> <br> I modified the realtime/bin/rtai-load script such that it loads rtai_sched without calibration: <br> <br> -- rtai-load=C2=A0=C2=A0 2018-03-20 18:32:15.317723122 +0100 <br> +++ /home/benda/rtai-load=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2018-= 03-21 15:53:59.619659835 +0100 <br> @@ -158,7 +158,9 @@ <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # one. If the latter fails too, assu= me the feature is built into <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler or not needed. Obvio= usly, we should _always_ find <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler... <br> -=C2=A0=C2=A0=C2=A0=C2=A0 if test -r $rtai_moddir/rtai_$mod$modext;= then <br> +=C2=A0=C2=A0=C2=A0=C2=A0 if test "x$mod" =3D "sched"; then <br> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo $insmod $rtai_mod= dir/rtai_$mod$modext kernel_latency=3D10 user_latency=3D10 <br> +=C2=A0=C2=A0=C2=A0=C2=A0 elif test -r $rtai_moddir/rtai_$mod$modex= t; then <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test $verbose =3D = 1 && echo "+ $insmod $rtai_moddir/rtai_$mod$modext" <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo $insmod $rta= i_moddir/rtai_$mod$modext <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if test $? =3D 0 ; then <br> <br> With that I can run all user tests (see latencies* file for test results (they are not great, but ok for a first shot) and infos on the machine, config* is the kernel configuration). <br> <br> Note that on the same machine we had rtai 4.1 running without problems. <br> <br> However, when I run the kern latency test the machine hangs up - not when insmoding rtai_sched but when executing the periodic task in kernel space. So comedi is not to blame here. <br> <br> Hanging up means the LEDs on the keyboard blink, the computer is inacessible, and I do not find any hints in the kernel log. <br> <br> I assume that the calibration feature in rtai_sched also runs a periodic task. <br> <br> So something goes wrong with the period tasks. <br> <br> Any ideas? <br> <br> I also could provide access to the machines. <br> <br> Best, <br> Jan <br> <br> <br> <br> On 03/15/2018 12:46 PM, Paul Pfeiffer wrote: <br> <blockquote type=3D"cite">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 module, that first chooses between oneshot and periodic mode (both lead to the same crash) <br> <br> ``` <br> #ifdef ONESHOT_MODE <br> =C2=A0=C2=A0 rt_set_oneshot_mode(); <br> =C2=A0=C2=A0 start_rt_timer(1); <br> #else <br> =C2=A0=C2=A0 rt_set_periodic_mode(); <br> =C2=A0=C2=A0 #endif <br> <br> ``` <br> <br> =C2=A0=C2=A0registers a real time task <br> <br> ``` <br> rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* dec= lare 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 versions 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> <br> _______________________________________________ <br> Rtai mailing list <br> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]= g">[email protected]</a> <br> <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/list= info/rtai</a> <br> <br> </blockquote> <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> --------------B36F2BF627E498CCAE64E6DC-- --===============2709783593597090088== 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 --===============2709783593597090088==--