Re: RTAI 5.0-test2 released

On 06/28/2016 02:11 AM, Paolo Mantegazza wrote:
> On 06/28/2016 09:30 AM, Paolo Mantegazza wrote:
>> On 06/27/2016 05:27 PM, Sebastian Kuzminsky wrote:
>>> On 06/27/2016 03:23 AM, Paolo Mantegazza wrote:
>>>> On 06/25/2016 05:11 PM, Sebastian Kuzminsky wrote:
>>>>> On 06/24/2016 02:19 AM, Paolo Mantegazza wrote:
>>>>> > If the problem is related to a lock due to many modules removal
>>>>> it is
>>>>> > difficult for me to say anything, especially in view of the use of a
>>>>> > virtual env. I've just a question: does the same happens out of a
>>>>> > virtualization?
>>>>>>
>>>>>> Paolo
>>>>>
>>>>> I just ran an over-night test on bare metal.  It ran much longer than
>>>>> in my virtual machines, but this morning it too had crashed.
>>>>>
>>>>> The console was blank and unresponsive, so i don't have any info to
>>>>> help debug this, sorry :-(
>>>>>
>>>>> I'd be happy to run any tests anyone would like.
>>>>>
>>>>>
>>>> I did not understand if you have problem in loading-unloading modules
>>>> under a virtual environment or just in running a test for a long time?
>>>> Paolo
>>>
>>> I spoke unclearly, apologies.
>>>
>>> My test consists of repeatedly building LinuxCNC and running the
>>> LinuxCNC test suite.
>>>
>>> The LinuxCNC test suite consists of ~180 tests.  Many of the tests
>>> run a sequence where they load the realtime modules (from RTAI and
>>> from LinuxCNC), exercise the code and check the results, then unload
>>> all the realtime modules.
>>>
>>> It's unknown to me where in this loop the bare-metal test failed.
>>>
>>> I've observed failures during unload in virtual machines. Here's a
>>> kernel log of two consecutive test cases from our test suite, where
>>> the machine locked up during unload on the second test case:
>>>
>>>>         [ 8780.404223] I-pipe: head domain RTAI registered.
>>>>         [ 8780.405262] RTAI[hal]: mounted. ISOL_CPUS_MASK: 1.
>>>>         [ 8780.406019] SYSINFO - # CPUs: 2, TIMER NAME: 'lapic',
>>>> TIMER IRQ: 2305, TIMER FREQ: 62502000, CLOCK NAME: 'tsc', CLOCK
>>>> FREQ: 2000081000, CPU FREQ: 2000081000, LINUX TIMER IRQ: 2305.
>>>>         [ 8780.414520] RTAI[malloc]: global heap size = 2097152
>>>> bytes, <BSD>.
>>>>         [ 8780.415838] , kstacks pool size = 524288 bytes.
>>>>         [ 8780.416828] RTAI[sched]: hard timer type/freq =
>>>> lapic/62502000(Hz); timing: oneshot; linear timed lists.
>>>>         [ 8780.418232] RTAI[sched]: Linux timer freq = 250 (Hz),
>>>> TimeBase freq = 2000081000 hz.
>>>>         [ 8780.419350] RTAI[sched]: timer setup = 1504 ns, resched
>>>> latency = 0 ns.
>>>>         [ 8780.449429] USERMODE CHECK: OK.
>>>>         [ 8780.449941] USERMODE CHECK PROVIDED (ns): KernelLatency
>>>> 8897, UserLatency 9087.
>>>>         [ 8780.451010] FINAL CALIBRATION SUMMARY (ns): KernelLatency
>>>> 8897, UserLatency 9087.
>>>>         [ 8780.455566] RTAI[math]: loaded, using NEWLIB.
>>>>         [ 8781.136562] RTAI[math]: unloaded.
>>>>         [ 8781.148269] SCHED releases registered named ALIEN PEDV$D
>>>>         [ 8781.169297] RTAI[malloc]: unloaded.
>>>>         [ 8781.268150] RTAI[sched]: unloaded (forced hard/soft/hard
>>>> transitions: traps 0, syscalls 0).
>>>>         [ 8781.273428] I-pipe: head domain RTAI unregistered.
>>>>         [ 8781.275513] RTAI[hal]: unmounted.
>>>
>>>>         [ 8781.356263] I-pipe: head domain RTAI registered.
>>>>         [ 8781.357292] RTAI[hal]: mounted. ISOL_CPUS_MASK: 1.
>>>>         [ 8781.358043] SYSINFO - # CPUs: 2, TIMER NAME: 'lapic',
>>>> TIMER IRQ: 2305, TIMER FREQ: 62502000, CLOCK NAME: 'tsc', CLOCK
>>>> FREQ: 2000081000, CPU FREQ: 2000081000, LINUX TIMER IRQ: 2305.
>>>>         [ 8781.366385] RTAI[malloc]: global heap size = 2097152
>>>> bytes, <BSD>.
>>>>         [ 8781.367682] , kstacks pool size = 524288 bytes.
>>>>         [ 8781.368639] RTAI[sched]: hard timer type/freq =
>>>> lapic/62502000(Hz); timing: oneshot; linear timed lists.
>>>>         [ 8781.370053] RTAI[sched]: Linux timer freq = 250 (Hz),
>>>> TimeBase freq = 2000081000 hz.
>>>>         [ 8781.371301] RTAI[sched]: timer setup = 1499 ns, resched
>>>> latency = 0 ns.
>>>>         [ 8781.401245] USERMODE CHECK: OK.
>>>>         [ 8781.401761] USERMODE CHECK PROVIDED (ns): KernelLatency
>>>> 8897, UserLatency 9087.
>>>>         [ 8781.402845] FINAL CALIBRATION SUMMARY (ns): KernelLatency
>>>> 8897, UserLatency 9087.
>>>>         [ 8781.407514] RTAI[math]: loaded, using NEWLIB.
>>>>         [ 8781.488021] RTAI[math]: unloaded.
>>>>         *** lockup here, while waiting for "SCHED releases
>>>> registered named ALIEN PEDV$D"
>>>
>>
>> OK I got it. From what you say, I see no reason for a running task to
>> work not. So, as a first step and sticking to what you show above, I
>> dare asking: what kind of object is "ALIEN PEDV$D"? Can you try to
>> have it closed by the code that uses it?
>> If that is not enough we'll see what else to do.
>> Paolo
>>
> Sorry, I forgot to ask you if tested tasks are in user or kernel space.
> The use of newlib suggests the latte, but I would like to be sure.
> Paolo

Yes, it's in kernel space.


-- 
Sebastian Kuzminsky
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai