Re: rt_task_wait_period hangs system
Paolo Mantegazza <[email protected]> Thu, 22 Mar 2018 12:59:33 +0100
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0837635004953924418== Content-Type: multipart/alternative; boundary="------------9DD3052B62CABBDB5A09667F" Content-Language: en-US This is a multi-part message in MIME format. --------------9DD3052B62CABBDB5A09667F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable "My software (www.relacs.net) runs now faster (upto 110kHz) ..."=C2=A0 is= =20 something I never seen. Here we never went beyond some 50KHz. So, welcome to the club of those thinking that kernel space is the only=20 way to achieve DSP like performances on general purpose CPUs, SMI=20 permitting. As for your excuses they are out of place. I know that RTAI=20 documentation is far from perfect. Moreover, before being reminded that=20 it could have been the cause of your trouble, after diffing you Linux=20 config against one of the mine, I even forgot it. The reason is that I=20 discovered such a trouble, reporting it in that README, in relation to a=20 test case associated to the use of RTAI netrpc support.To me it never=20 happened in something as simple as the latency test. Thats said I dare asking you to verify that it was also the cause of the=20 self calibration failur/e, as it should be. /It will not be much work.=20 Simply "rm rtai_install_dir/calibration/latencies" and run any test, or=20 even your production code, insomoding rtai_sched.ko without any parameter= . Then, when you'll have time to recompile the kernel, I'm curious to know=20 if the kernel latency test will still work in your system environment=20 after setting the STACKPROTECTOR parameter to REGULAR. Anticipated thanks, Paolo. On 03/22/2018 11:52 AM, Jan Benda wrote: > Hi Paolo, > > thank you for your hints regarding the configuration. > > To make it short, the STACKPROTECTOR stuff solved my issue. My=20 > software (www.relacs.net) runs now faster (upto 110kHz) and more=20 > stable than ever before. Thank you for whatever improvements went into=20 > RTAI 5.1! > > 1) CONFIG_AUDITSYSCALL was unset: > > CONFIG_AUDIT=3Dy > CONFIG_HAVE_ARCH_AUDITSYSCALL=3Dy > # CONFIG_AUDITSYSCALL is not set > > CONFIG_HAVE_ARCH_AUDITSYSCALL cannot be unset from the menu. > > 2) Indeed I missed your note on stack protector support. Mea culpa! I=20 > set it to "None" and that solved the issue. > > Sorry for missing this! Maybe I stopped reading because I was sure=20 > (why?) that I am not witnessing a stack protector crash... > > Best, > Jan > > > On 03/21/2018 10:02 PM, Paolo Mantegazza wrote: >> Before I'll access your system, let's see if there is any trivial=20 >> problem left. >> >> =C2=A0From your LInux config I see that there are 2 forgotten suggesti= ons,=20 >> as given in README.CONF_RMRKS. >> >> One is that AUDITSYSCALL is enabled, which, since there seems to be=20 >> no problem from user space, should not be the cause of our troubles. >> >> The other one instead, i.e.: CONFIG_HAVE_CC_STACKPROTECTOR=3Dy,=20 >> CONFIG_CC_STACKPROTECTOR=3Dy, CONFIG_CC_STACKPROTECTOR_STRONG=3Dy, may= be. >> Thus, disable all of the STACKPROTECTOR options, including the=20 >> REGULAR one, recompile the kernel and retry. >> Then let me know. >> >> If we'll still be in trouble, the I'll access your system. >> >> Paolo >> >> ________________________________________ >> From: Rtai [[email protected]] on behalf of Jan Benda=20 >> [[email protected]] >> Sent: Wednesday, March 21, 2018 6:01 PM >> To: [email protected] >> Subject: Re: [Rtai] rt_task_wait_period hangs system >> >> Thank you Paolo for the quick response! >> >> On 03/21/2018 05:21 PM, Paolo Mantegazza wrote: >>> First of all, if you can let me in your system I'm ready to take the >>> burden of trying to understand what is happening. >>> 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 system ca= n go >>> ashtray without any trouble for anybody. I do not want to be hold >>> responsible for anything. >>> On your side you must be ready to be flooded by emails (or phone call= s) >>> to push the reset switch of your system. >> >> I am ready and send you an email with the necessary details. >> >>> 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. >> >> This is my imrepssion as well - its strange. In particular given the >> latency test without overruns. >> >>> BTW, have you run also the kthread latency test? Let ime know about i= t >>> too, please. >> >> Attached is the kthreads test. This works as well. Only the switch tes= t >> does not report on the terminal (it complains about /var/log/messages >> not being there - it is indeed not enabled), but the output of dmesg >> shows the results (at end of the attached file). >> >>> 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 poin= t >>> that of being a bit too optimistic. Likely taken for short time check= s >>> with Linux unloaded. >> >> With "not great" I only meant that I know that with some effort I migh= t >> get them better. And you are right, they are taken on a machine withou= t >> load as a first check whether things are working. I am actually amazed >> that on a first shot without any tweaking I got these latencies. This = is >> my general impression with rtai-5.1 that - in case it works - I get >> already quite good latencies. First shot means that I start out with t= he >> configuration of a matching lowlatency kernel, change a few kernel >> configs, and run localmodconfig. >> >> Jan >> >>> To have them better I usually have to resort to CPU isolation, matche= d >>> 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 >>>> several intel i3, i5 and i7 machines. The results are mixed - some >>>> work out of the box without tweaking (which is really cool) but othe= rs >>>> hang up when insmoding rtai_sched - i.e. when it runs the calibratio= n. >>>> Loading rtai_sched with kernel_latency=3D10 user_latency=3D10, as >>>> suggested, works always (no calibration). >>>> >>>> I modified the realtime/bin/rtai-load script such that it loads >>>> 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-0= 3-21 15:53:59.619659835 +0100 >>>> @@ -158,7 +158,9 @@ >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # one. If the latter fails too,= assume the feature is built=20 >>>> into >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler or not needed. = Obviously, we should _always_=20 >>>> find >>>> =C2=A0=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; = then >>>> +=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_modd= ir/rtai_$mod$modext kernel_latency=3D10 >>>> user_latency=3D10 >>>> +=C2=A0=C2=A0=C2=A0=C2=A0 elif test -r $rtai_moddir/rtai_$mod$modext= ; then >>>> =C2=A0=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" >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo $insmod= $rtai_moddir/rtai_$mod$modext >>>> =C2=A0=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 >>>> results (they are not great, but ok for a first shot) and infos on t= he >>>> machine, config* is the kernel configuration). >>>> >>>> Note that on the same machine we had rtai 4.1 running without=20 >>>> problems. >>>> >>>> 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. >>>> >>>> Hanging up means the LEDs on the keyboard blink, the computer is >>>> inacessible, and I do not find any hints in the kernel log. >>>> >>>> I assume that the calibration feature in rtai_sched also runs a >>>> 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 >>>>> 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. >>>>> >>>>> System info: >>>>> RTAi 5.1, Kernel 4.9.76, Intel i5-6600K >>>>> >>>>> In detail, the call happens in a custom kernel module, that first >>>>> chooses between oneshot and periodic mode (both lead to the same=20 >>>>> crash) >>>>> >>>>> ``` >>>>> #ifdef ONESHOT_MODE >>>>> =C2=A0=C2=A0=C2=A0 rt_set_oneshot_mode(); >>>>> =C2=A0=C2=A0=C2=A0 start_rt_timer(1); >>>>> #else >>>>> =C2=A0=C2=A0=C2=A0 rt_set_periodic_mode(); >>>>> =C2=A0=C2=A0=C2=A0 #endif >>>>> >>>>> ``` >>>>> >>>>> =C2=A0=C2=A0 registers a real time task >>>>> >>>>> ``` >>>>> rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* decla= re if we use the FPU */ >>>>> >>>>> retVal =3D rt_task_init( &dynClampTask.rtTask, dynclamp_loop, dummy= , >>>>> stackSize, priority, usesFPU, signal ); >>>>> ``` >>>>> >>>>> and then makes it periodic >>>>> >>>>> ``` >>>>> rt_task_make_periodic( &dynClampTask.rtTask, rt_get_time() + >>>>> 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 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? >>>>> >>>>> Maybe related, I have recently been reporting my diffuculties >>>>> installing RTAI 5.1, especially the system hig up when rtai_sched w= as >>>>> loaded. Thanks to the help of Paolo, see thread "RTAI in debian 9", >>>>> this problem was fixed via manual generation of a calibration file. >>>>> >>>>> Sorry, for the long question, but we are really eager to use the >>>>> 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 >>> >>> >> >> >> --=20 >> ---------------------------------------------------------------------- >> >> Prof. Dr. Jan Benda >> Abteilung Neuroethologie >> Institut fuer Neurobiologie >> Universitaet Tuebingen >> Auf der Morgenstelle 28 E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 phone: +49 / 7071 - 2= 9 74573 >> 72076 Tuebingen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fax: +49 / 7071 - 29 5144 >> >> ---------------------------------------------------------------------- >> > > --------------9DD3052B62CABBDB5A09667F 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">"My software (<a class=3D"moz-txt-link= -abbreviated" href=3D"http://www.relacs.net">www.relacs.net</a>) runs now faster (upto 110kHz) ..."=C2=A0 is something I never seen. Here we never went beyond some 50KHz.<br> So, welcome to the club of those thinking that kernel space is the only way to achieve DSP like performances on general purpose CPUs, SMI permitting.<br> <br> As for your excuses they are out of place. I know that RTAI documentation is far from perfect. Moreover, before being reminded that it could have been the cause of your trouble, after diffing you Linux config against one of the mine, I even forgot it. The reason is that I discovered such a trouble, reporting it in that README, in relation to a test case associated to the use of RTAI netrpc support.To me it never happened in something as simple as the latency test. <br> <br> Thats said I dare asking you to verify that it was also the cause of the self calibration failur<i>e, as it should be. </i>It will not be much work. Simply "rm rtai_install_dir/calibration/latencies" and run any test, or even your production code, insomoding rtai_sched.ko without any parameter. <br> <br> Then, when you'll have time to recompile the kernel, I'm curious to know if the kernel latency test will still work in your system environment after setting the STACKPROTECTOR parameter to REGULAR.<= br> <br> Anticipated thanks, Paolo.<br> <br> On 03/22/2018 11:52 AM, Jan Benda wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]">= Hi Paolo, <br> <br> thank you for your hints regarding the configuration. <br> <br> To make it short, the STACKPROTECTOR stuff solved my issue. My software (<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.= relacs.net">www.relacs.net</a>) runs now faster (upto 110kHz) and more stable than ever before. Thank you for whatever improvements went into RTAI 5.1! <br> <br> 1) CONFIG_AUDITSYSCALL was unset: <br> <br> CONFIG_AUDIT=3Dy <br> CONFIG_HAVE_ARCH_AUDITSYSCALL=3Dy <br> # CONFIG_AUDITSYSCALL is not set <br> <br> CONFIG_HAVE_ARCH_AUDITSYSCALL cannot be unset from the menu. <br> <br> 2) Indeed I missed your note on stack protector support. Mea culpa! I set it to "None" and that solved the issue. <br> <br> Sorry for missing this! Maybe I stopped reading because I was sure (why?) that I am not witnessing a stack protector crash... <br> <br> Best, <br> Jan <br> <br> <br> On 03/21/2018 10:02 PM, Paolo Mantegazza wrote: <br> <blockquote type=3D"cite">Before I'll access your system, let's see if there is any trivial problem left. <br> <br> =C2=A0From your LInux config I see that there are 2 forgotten suggestions, as given in README.CONF_RMRKS. <br> <br> One is that AUDITSYSCALL is enabled, which, since there seems to be no problem from user space, should not be the cause of our troubles. <br> <br> The other one instead, i.e.: CONFIG_HAVE_CC_STACKPROTECTOR=3Dy, CONFIG_CC_STACKPROTECTOR=3Dy, CONFIG_CC_STACKPROTECTOR_STRONG=3Dy= , maybe. <br> Thus, disable all of the STACKPROTECTOR options, including the REGULAR one, recompile the kernel and retry. <br> Then let me know. <br> <br> If we'll still be in trouble, the I'll access your system. <br> <br> Paolo <br> <br> ________________________________________ <br> From: Rtai [<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:= [email protected]">[email protected]</a>] on behalf of Jan Benda [<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:jan.benda@u= ni-tuebingen.de">[email protected]</a>] <br> Sent: Wednesday, March 21, 2018 6:01 PM <br> To: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:rtai@rta= i.org">[email protected]</a> <br> Subject: Re: [Rtai] rt_task_wait_period hangs system <br> <br> Thank you Paolo for the quick response! <br> <br> On 03/21/2018 05:21 PM, Paolo Mantegazza wrote: <br> <blockquote type=3D"cite">First of all, if you can let me in your system I'm ready to take the <br> burden of trying to understand what is happening. <br> Even if in 20 years of RTAI development-usage I lost my system just <br> three times. Nonetheless it would be better if=C2=A0 such a sys= tem can go <br> ashtray without any trouble for anybody. I do not want to be hold <br> responsible for anything. <br> On your side you must be ready to be flooded by emails (or phone calls) <br> to push the reset switch of your system. <br> </blockquote> <br> I am ready and send you an email with the necessary details. <br> <br> <blockquote type=3D"cite">I'm a bit curious to see why neither th= e calibration nor the kernel <br> space latency test are running. The latter is a bit strange indeed, <br> especially in view of the fact that 4.1 is OK. In fact the changes of <br> 5.1 should affect user space, mostly. <br> </blockquote> <br> This is my imrepssion as well - its strange. In particular given the <br> latency test without overruns. <br> <br> <blockquote type=3D"cite">BTW, have you run also the kthread latency test? Let ime know about it <br> too, please. <br> </blockquote> <br> Attached is the kthreads test. This works as well. Only the switch test <br> does not report on the terminal (it complains about /var/log/messages <br> not being there - it is indeed not enabled), but the output of dmesg <br> shows the results (at end of the attached file). <br> <br> <blockquote type=3D"cite">As a final comment I do not share the fact that max latencies in the <br> range of 10-15 (us) are not great. To me they are indeed, to the point <br> that of being a bit too optimistic. Likely taken for short time checks <br> with Linux unloaded. <br> </blockquote> <br> With "not great" I only meant that I know that with some effort I might <br> get them better. And you are right, they are taken on a machine without <br> load as a first check whether things are working. I am actually amazed <br> that on a first shot without any tweaking I got these latencies. This is <br> my general impression with rtai-5.1 that - in case it works - I get <br> already quite good latencies. First shot means that I start out with the <br> configuration of a matching lowlatency kernel, change a few kernel <br> configs, and run localmodconfig. <br> <br> Jan <br> <br> <blockquote type=3D"cite">To have them better I usually have to resort to CPU isolation, matched <br> to a few other things I forgot. <br> <br> Paolo. <br> <br> On 03/21/2018 04:21 PM, Jan Benda wrote: <br> <blockquote type=3D"cite">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 <br> several intel i3, i5 and i7 machines. The results are mixed - some <br> work out of the box without tweaking (which is really cool) but others <br> hang up when insmoding rtai_sched - i.e. when it runs the calibration. <br> Loading rtai_sched with kernel_latency=3D10 user_latency=3D10= , as <br> suggested, works always (no calibration). <br> <br> I modified the realtime/bin/rtai-load script such that it loads <br> 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=C2=A0 # one. If the latter fai= ls too, assume the feature is built into <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # the scheduler or not n= eeded. Obviously, we should _always_ find <br> =C2=A0=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$m= odext; 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 $rt= ai_moddir/rtai_$mod$modext kernel_latency=3D10 <br> user_latency=3D10 <br> +=C2=A0=C2=A0=C2=A0=C2=A0 elif test -r $rtai_moddir/rtai_$mod= $modext; then <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test $= verbose =3D 1 && echo "+ $insmod <br> $rtai_moddir/rtai_$mod$modext" <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $sudo = $insmod $rtai_moddir/rtai_$mod$modext <br> =C2=A0=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 <br> results (they are not great, but ok for a first shot) and infos on the <br> 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 <br> when insmoding rtai_sched but when executing the periodic task in <br> kernel space. So comedi is not to blame here. <br> <br> Hanging up means the LEDs on the keyboard blink, the computer is <br> 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 <br> 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 <br> trying to run production code, which leads to a system crash. <br> Debgugging lead me to conclude that it is the call to <br> 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 <br> chooses between oneshot and periodic mode (both lead to the same crash) <br> <br> ``` <br> #ifdef ONESHOT_MODE <br> =C2=A0=C2=A0=C2=A0 rt_set_oneshot_mode(); <br> =C2=A0=C2=A0=C2=A0 start_rt_timer(1); <br> #else <br> =C2=A0=C2=A0=C2=A0 rt_set_periodic_mode(); <br> =C2=A0=C2=A0=C2=A0 #endif <br> <br> ``` <br> <br> =C2=A0=C2=A0 registers a real time task <br> <br> ``` <br> rt_linux_use_fpu( usesFPU );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = /* declare if we use the FPU */ <br> <br> retVal =3D rt_task_init( &dynClampTask.rtTask, dynclamp_loop, dummy, <br> stackSize, priority, usesFPU, signal ); <br> ``` <br> <br> and then makes it periodic <br> <br> ``` <br> rt_task_make_periodic( &dynClampTask.rtTask, rt_get_time() + <br> 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 R= TAI versions <br> and on other machines, so we were wondering whether this a 5.1 <br> specific problem or related to our new machine? For completeness, I <br> attach the source code of the kernel module, the functions of <br> interest are dynclamp_loop, init_dynclamp_loop and <br> cleanup_dynclamp_loop. Any ideas? <br> <br> Maybe related, I have recently been reporting my diffuculties <br> installing RTAI 5.1, especially the system hig up when rtai_sched was <br> loaded. Thanks to the help of Paolo, see thread "RTAI in debian 9", <br> 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 <br> 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:Rtai@r= tai.org">[email protected]</a> <br> <a class=3D"moz-txt-link-freetext" href=3D"https://mail.rta= i.org/cgi-bin/mailman/listinfo/rtai">https://mail.rtai.org/cgi-bin/mailma= n/listinfo/rtai</a> <br> <br> </blockquote> <br> <br> <br> <br> _______________________________________________ <br> Rtai mailing list <br> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Rtai@rta= i.org">[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/= listinfo/rtai</a> <br> </blockquote> <br> <br> </blockquote> <br> <br> -- <br> ---------------------------------------------------------------------- <br> <br> Prof. Dr. Jan Benda <br> Abteilung Neuroethologie <br> Institut fuer Neurobiologie <br> Universitaet Tuebingen <br> Auf der Morgenstelle 28 E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 phone: +49 / 7071 = - 29 74573 <br> 72076 Tuebingen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fax: +49 / 7071 - 29 5144 <br> <br> ---------------------------------------------------------------------- <br> <br> </blockquote> <br> <br> </blockquote> <p><br> </p> </body> </html> --------------9DD3052B62CABBDB5A09667F-- --===============0837635004953924418== 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 --===============0837635004953924418==--