#linuxcnc-devel Logs

May 07 2020

03:11 PM jepler: I got the rtai_hirq_dispatcher crash with just the rtai latency test, no linuxcnc. iteration 1182. https://gist.github.com/212d2093f7feb22232f6d2a432e9cacd
03:15 PM jepler: root@debian10rtai:/usr/realtime-4.14.174-rtai-amd64/testsuite# while sync; do /usr/realtime-4.14.174-rtai-amd64/bin/rtai-load /usr/realtime-4.14.174-rtai-amd64/testsuite/.runinfo; sleep .1; /usr/realtime-4.14.174-rtai-amd64/bin/rtai-load cleanup; echo Iteration $((++i)) done; done
03:15 PM jepler: andypugh memfrob skunkworks
05:06 PM skunkworks: jepler: shouldn't this be something the rtai people/person should be able to see then?
05:07 PM jepler: Seems like
05:13 PM jepler: but it also seems like it might be a different _thing_ than what andypugh was chasing, because his required a "loadrt threads", and this doesn't do a step like that. so, there may be two problems, and this is the less frequent one. But, it's the only problem I saw while using uspace-rtai so maybe the traditional kernel rtai *ONLY* is affected by the original problem. I looked for andypugh's and seb's info about the
05:13 PM jepler: tracebacks but didn't find it. I thought there were screenshots of oopses or something.
05:16 PM seb_kuzminsky: http://highlab.com/~seb/linuxcnc/rtai-crash.2020-04-24/
05:17 PM seb_kuzminsky: those are with some recent version of Andy's rtai packages, running linuxcnc's runtests in a loop
05:51 PM jepler: seb_kuzminsky the last one is the same as mine
05:51 PM jepler: It's the only one I've seen here