Back
[09:53:10] -moorcock.freenode.net:#linuxcnc-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp
[10:48:41] <mhaberler> hm, there seems to be a way to force a Xenomai RT thread back to primary (RT mode) after it has been relegated to linux-class scheduling; that means it is a reversible operation: see T_CONFORMING
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__task.html#ga915e7edfb0aaddb643794d7abc7093bf
[10:49:43] <mhaberler> meaning all thread systems have the same semantics - an RT violation is recorded but RT mode continues
[10:53:00] <pcw_home> Thats probably for the best as a RT timing violation may be minor enough in some cases
[10:53:01] <pcw_home> that its best to muddle on (and in any case RT shutdown should be up to user choice in these cases)
[10:54:05] <mhaberler> right, I'll record faults in a hal pin in hal_lib.c and a way to convey an estop signal associated with a limit on faults
[10:55:13] <mhaberler> maybe not the absolute count but the rate could be considered
[10:55:24] <cradek> oh that's good news
[12:37:04] <mhaberler> jepler: xenomai would actually give useful stats:
http://www.xenomai.org/documentation/xenomai-2.6/html/api/structrt__task__info.html ; unfortunately thats xenomai-only; both modeswitches and pagefaults
[12:45:04] <CaptHindsight> Lars and Alec are working on some in kernel debugger to trace the pagefaults and any other issue if it turns out to not be pagefaults causing the RT-PREEMPT problems
[12:45:29] <CaptHindsight> this should be interesting
[12:58:36] <mhaberler> jepler: around? I'm considering flavor-specific pins in hal_lib for stats; this would help pinpointing problems much more accurately, for instance in xenomai one could pinpoint pf's, involuntary mode switches etc at the thread level (besides optionally backtracing the frame which caused a mode switch)
[12:59:55] <mhaberler> also, turns out the permanent switch to linux scheduling was a red herring; this happens only temporarily until one of several Xenomai calls, including rt_task_wait_period(), all of which switch back the thread to primary mode
[13:00:45] <mhaberler> so in fact there's nothing to do except report/set halpins in the SIGXCPU handler which executes in linux mode
[13:20:00] <dgarr> i wanted to test a recent buildbot deb for lucid, master,sim,i386 but it complained about libmodbus5
[13:20:10] <dgarr> transcript:
http://www.panix.com/~dgarrett/stuff/l.txt
[13:20:32] <dgarr> i forced install but wonder is this a bug or is there a deb for libmodbus5 for lucid?
[13:21:47] <mhaberler> Seb created one, yes
[13:22:35] <cradek> deb
http://linuxcnc.org/ lucid base
[13:23:00] <cradek> ^ add this to sources.list
[13:23:13] <dgarr> ok thanks
[13:23:43] <cradek> then I think to fix it up: apt-get update; apt-get -f install
[13:24:58] <cradek> dgarr: thanks for working on packaging
[13:26:51] <dgarr> i'm struggling with packaging -- i've worked mostly in precise and some things not working with lucid, it make take some time yet