Re: stalls with 4.1.18 and rtai 5.0~test2

Thanks, I applied all the patches related to the code, as found at: //highlab.com/~seb/rtai/stall.2016-08-18/patches-for-rtai.org/ .
The configure ones will be cared of by Pierangelo, when he'll return from his holidays.
Please check the changes in vulcano CVS, along with Changelog.

The only real  bugs are those related to the old registry way and to the redundant, albeit unharmful, spin unlock in hash_ins_adr.
The missing spin unlocks are formally wrong and has been corrected, albeit being useless, the list being structured in such a way that one of the two branches of the if-then-else should (must in their author's intention) be satisfied, always. 
The other two fixes makes the code more stylish but do not affect its correctnessl.

Therefore I'm not surprised they do not change the behavior of your flood launch tests. I know I've a promise pending but up to now I did not find the time to go after it.  That does not mean it has been forgotten.

Thanks again, Paolo.

________________________________________
From: Rtai [[email protected]] on behalf of Sebastian Kuzminsky [[email protected]]
Sent: Thursday, August 18, 2016 10:54 PM
To: [email protected]
Subject: [Rtai] stalls with 4.1.18 and rtai 5.0~test2

Hello RTAI devs, I'm back with another bug report.

I saw that the 4.1.18 patch was updated recently, so i built the kernel
and the rtai modules and booted it in an amd64 VM.  (I know VMs can not
provide good realtime performance, but they are convenient for
correctness-testing.)

I then ran the "testsuite/kernel/preempt" test in a loop: start the
test, let it run for a couple of seconds, then kill the "display"
process so it unloads and cleans up everything, then repeat.

It hung within a few hours with "rcu stall" errors.

My kernel config, dmesg, and a pstree after the stall are here:

        http://highlab.com/~seb/rtai/stall.2016-08-18/

My kernel is the vanilla 4.1.18 from kernel.org, plus the debian
patches, plus hal-linux-4.1.18-x86-6.patch (md5sum
56e67a9244ea0db99f9778fa6bab0b08).

My rtai source was updated from CVS on 2016-08-16.

My virtual machine has 2 CPUs (no isolcpus kernel argument was used) and
2 GB RAM.  It is running an up-to-date Debian Jessie.


I initially suspected lxrt_list locking errors in base/sched/api.c, and
indeed i found some problems in that area, but even after fixing them
the hang remains.

My lxrt_list locking patches (and some other minor changes) are
available here and I offer them to you for review and inclusion in
rtai.org's CVS repo:

        http://highlab.com/~seb/rtai/stall.2016-08-18/patches-for-rtai.org/


I also ran into similar problems while running the linuxcnc test suite
on this VM and a similarly configured one running 686-pae kernel, look
in the linuxcnc-tests directory if you want to see those details.


--
Sebastian Kuzminsky
_______________________________________________
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