We have a couple of candidate RTAI kernels (4.14.174-rtai /
4.19.114-rtai) that nearly, but not quite, work.
There seems to be a problem loading or unloading RTAI, leading to a
kernel panic and system freeze.
Typically 1 time in 200.
The system appears to run perfectly between startup and shutdown. But
it does mean that the buildbot / runtests can be a problem. If you run
runtests in a loop you will typically see a problem in less than 2
hours.
Seb has found a script that makes the problem appear in about 5 minutes.
#!/bin/bash
sudo dmesg -c > /dev/null
rm ${HOME}/test-results/*
source ${HOME}/linuxcnc-dev/scripts/rip-environment
for PASS in $(seq 1 1000); do
echo starting pass ${PASS}
runtests ${HOME}/linuxcnc-dev/tests/abs.0
# uncomment these lines to make it crash less often
#DMESG=$(printf "${HOME}/test-results/dmesg.%04d" ${PASS})
#sudo dmesg -c > ${DMESG}
#cat ${DMESG} | cut -d ] -f 2- > ${DMESG}.cut
#sync
done
I have tried stepping back to LinuxCNC v 2.6 (ie to before uspace) to
see if a git bisect in LinuxCNC was worth trying, but I couldn't
persuade 2.6 to build in 64-bit buster.
I tried 2.7, and the problem is the same there.
A similar problem applies with trying to bisect RTAI. I am building
from the NTULINUX repostpry and that only goes back to RTAI v5.2, and
that also contains many non-building variants.
So, any ideas how to attack this issue?
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
