Re: RTAI 5.0-test2 released

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
>>
>> And of course, all these tests run fine with our earlier (3.9-era and 
>> older) versions of 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