#linuxcnc-devel Logs

Sep 15 2017

01:24 AM linuxcnc-build: Hey! build 0000.checkin #5135 is complete: Success [3build successful]
01:25 AM linuxcnc-build: Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5135
02:44 AM memfrob: I got the new RTAI latency testsuite going, calibration errors still show up in dmesg but no other issues, for all I know, those self calibration errors are safe to ignore. If you know anything about this, let CaptHindsight know so he can pass it on to me.
05:58 AM jepler: looking at the code near printk("USERMODE CHECK: %s.\n", !call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC) ? "OK" : "ERROR");
05:58 AM jepler: one oddity I spot is that envp[0] is not a proper environment string char env0[] = RTAI_INSTALL_DIR"/calibration";
05:58 AM jepler: I don't know what the consequences of that are
06:00 AM jepler: the consequence of the calibration helper not running at all is, latencies of usermode are not gathered and so the performance of rtai in usermode is going to be degraded
06:01 AM jepler: that's unimportant for LinuxCNC 2.7, but important for 2.8 where we have the ability to use RTAI LXRT ("uspace+rtai" in our terminology)
06:04 AM jepler: both of those look like they might as well be completely rewritten at commit da69a5c123b17c80f9dccc4ba50bb5c41ed464dc but it looks like the way the git history is managed you can't tell which parts of the huge rewrites are the git committer's, and which parts are from upstream RTAI 5. which is ironic in a way
06:10 AM jepler: CaptHindsight: ^
07:25 AM jepler: spotted on the nasa feed: windows from "xv 3.10a", a very old image viewer. and that window manager must be motif or an ancient imitator like fvwm2
07:27 AM jepler: bye cassini
12:58 PM -!- #linuxcnc-devel mode set to +v by ChanServ
01:12 PM CaptHindsight: jepler: noted
02:18 PM jepler: might just verify whether the program is even installed to the expected location, and find out what happens if you try invoking it to yourself\
04:37 PM memfrob: jepler, I'm not a C guru and I usually don't see actual paths in C, what's wrong with env0[] ?
04:38 PM memfrob: char arg0[] and char arg1[] use the same syntax
04:38 PM memfrob: I didn't write those by the way so that would be upstream RTAI
04:42 PM memfrob: rtai_defs.h (generated by autogen.sh in my tree) contains RTAI_INSTALL_PATH and is included into sched.c
04:42 PM memfrob: #define RTAI_INSTALL_DIR "@RTAI_INSTALL_DIR@"
04:44 PM memfrob: Actually, shouldn't rtai_defs.h.in be "@RTAI_INSTALL_DIR@" instead of "%RTAI_INSTALL_DIR%"
04:45 PM memfrob: "%RTAI_INSTALL_DIR%" is used in rtai_defs.h.in which autoreconf turns % into @ but with all my knowledge of how autotools works, using @ would turn RTAI_INSTALL_DIR into the actual installation directory, not turning one variable into another.
04:49 PM memfrob: Upstream RTAI actually got cute, they use sed to replace % to @ in the makefile but this is an autotools job, not a makefile job. I'll re-work the structure a bit, but hard-code RTAI_INSTALL_DIR first to the real path on my system and see if it fixes anything before doing it the right way
05:08 PM jepler: memfrob: things in "envp" are environment variables, so normally they're expected to have the form FOO=bar
05:12 PM memfrob: Well he's got 7 lines of environment settings going on so you got me.
05:16 PM memleak: kernel panic, if you said anything else after that I missed it.
05:17 PM memleak: jeeze, RTAI 5 is really unstable.
05:17 PM jepler: nope
05:17 PM memleak: This is truly horrible.
05:17 PM jepler: :-/ unstable kernels are a drag
05:18 PM jepler: crashy ones, that is. Ones from "debian unstable" are usually OK
05:18 PM memleak: My RTAI release that I've been using for the past few years haven't given me any issues.
05:19 PM memleak: the kernel itself is fine, I just went to unload rtai_sched and that's when I had problems.
05:19 PM memleak: Not once in the master branch.
05:40 PM jepler: this sounds similar to the problem that seb_kuzminsky has experienced trying to build Paolo's tree
05:41 PM jepler: discussed e.g., in this thread http://rtai.rtai.narkive.com/oc6Op7Kc/rtai-5-0-test2-released
05:42 PM jepler: I guess it's not surprised if this unfixed problem has invaded your tree too :-/
05:43 PM jepler: oh look a familiar name at the bottom of the threa
05:43 PM jepler: d
05:46 PM memfrob: jepler, thank you!!
05:47 PM memfrob: [ 395.700254] USERMODE CHECK: OK. [ 395.700258] USERMODE CHECK PROVIDED (ns): KernelLatency 1333, UserLatency 1576. [ 395.700259] FINAL CALIBRATION SUMMARY (ns): KernelLatency 1333, UserLatency 1576.
05:48 PM memfrob: RTAI_INSTALL_DIR is screwed up in upstream is all, I can fix that easy. I had no idea that's what it could be.
06:08 PM jepler: great! I'm glad I could help.
06:49 PM memfrob: https://github.com/NTULINUX/RTAI/commit/a474e03e64c9f5b29a575ebaf1e52458b14e2596
06:50 PM memfrob: Thanks again!
10:39 PM memfrob: Am I the only one suffering from constant kernel hard locks with RTAI 5?
10:45 PM memfrob: I just loaded and unloaded RTAI several times, no issues, but sometimes on unloading, the system freezes. Results of unload/reload: http://dpaste.com/0X37R02
10:49 PM memfrob: Oh no wonder! RTAI reverts the time keeping fixes done by the Xenomai developers to avoid this specific issue I'm having. So I need to undo RTAI's IPIPE modifications.
11:01 PM memfrob: Looks like I'll also have to cherry-pick this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=ec02b076ceab63f99e5b3d80fd223d777266c236
11:01 PM memfrob: Another day. take care everybody and thanks for the help