Re: rt_task_wait_period hangs system

Hi,

On 21/03/18 15:21, 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 others hang up when
> insmoding rtai_sched - i.e. when it runs the calibration. Loading
> rtai_sched with kernel_latency=10 user_latency=10, as suggested, works
> always (no calibration).
>
> I modified the realtime/bin/rtai-load script such that it loads
> rtai_sched without calibration:
>
> -- rtai-load   2018-03-20 18:32:15.317723122 +0100
> +++ /home/benda/rtai-load       2018-03-21 15:53:59.619659835 +0100
> @@ -158,7 +158,9 @@
>        # one. If the latter fails too, assume the feature is built into
>        # the scheduler or not needed. Obviously, we should _always_ find
>        # the scheduler...
> -     if test -r $rtai_moddir/rtai_$mod$modext; then
> +     if test "x$mod" = "sched"; then
> +        $sudo $insmod $rtai_moddir/rtai_$mod$modext kernel_latency=10
> user_latency=10
> +     elif test -r $rtai_moddir/rtai_$mod$modext; then
>           test $verbose = 1 && echo "+ $insmod
> $rtai_moddir/rtai_$mod$modext"
>           $sudo $insmod $rtai_moddir/rtai_$mod$modext
>          if test $? = 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 the 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
> 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.

This is a kernel panic. Most likely a NULL pointer dereference in the 
kernel. To get the information about the 'panic' you will need to enable 
a serial console (assuming your hardware has serial ports) as the system 
stops before anything can be written to the log files but after writing 
the stack back trace etc. to the serial console.

Regards
	Mark.

>
> 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 crash)
>>
>> ```
>> #ifdef ONESHOT_MODE
>>    rt_set_oneshot_mode();
>>    start_rt_timer(1);
>> #else
>>    rt_set_periodic_mode();
>>    #endif
>>
>> ```
>>
>>   registers a real time task
>>
>> ```
>> rt_linux_use_fpu( usesFPU );      /* declare if we use the FPU */
>>
>> retVal = 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.  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?
>>
>> 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.
>>
>> 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
>
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai