Back
[00:17:32] <KGB-linuxcnc> 03seb 05master d33b1e3 06linuxcnc 10src/hal/user_comps/gs2_vfd.c * fix a config reporting bug in gs2_vfd
[01:33:30] <KGB-linuxcnc> 03chrisinnanaimo 05master 065e5a9 06linuxcnc 10lib/python/gladevcp/hal_sourceview.py * gladevcp -allow reloading the buffer with the same file -hal_sourceview
[01:33:30] <KGB-linuxcnc> 03chrisinnanaimo 05master 13a6d9a 06linuxcnc 10configs/sim/gscreen_custom/industrial_handler.py 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -check for edits in gcode -pop dialog for save request
[07:49:03] <skunkworks_> micges, did you mention this weekend that I needed to link to lib? what and how was that?
[07:49:56] <micges> what context? mesaflash or 7i80?
[07:50:32] <micges> ah
[07:51:13] <micges> I confirm that even after installing headers for xeno 3.5.7 kernel you must create link in /lib/modules/..
[07:51:44] <micges> it is minor bug in those xeno packages
[07:54:56] <micges> skunkworks_: ^^
[08:18:09] <skunkworks_> ah
[08:21:55] <skunkworks_> yes
[08:49:32] <skunkworks_> pcw_home, miches I made some changes to the wiki
[08:49:33] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai
[08:52:06] <pcw_home> Any luck with 12.04?
[08:55:29] <pcw_home> I tested the watchdog hardware and its seems OK
[08:57:18] <skunkworks_> pcw_home, no - I don't know what to do. jepler had some sugestions but that is above my pay grade
[08:57:41] <pcw_home> so the watchdog thing is likely a bug, and the hardware has not been enabled
[08:58:01] <skunkworks_> ah - ok
[08:58:20] <skunkworks_> when you said it was ok - I was going to ask why the led stayed on ;)
[08:58:44] <skunkworks_> So the config line doesn't seem to be sent to the card?
[08:58:58] <pcw_home> Beacuse the watchdog hardware didn't get enabled probably due to a driver bug
[08:59:10] <skunkworks_> right
[08:59:48] <pcw_home> which is a really good argument that the driver should verify watchdog operation every startup
[09:01:50] <pcw_home> the watchdog requires very specific operation to reset(specific data written to a specific location), but unless the timeout is set, its disabled
[09:02:47] <skunkworks_> it bites - like I get the watch.dog has bitten going true. It just doesn't do what ever it is supposed to in the card.
[09:03:03] <skunkworks_> ah
[09:13:40] <pcw_home> I suspect the timeout was never set
[09:13:57] <pcw_home> so it will always have a has bitten indicator
[09:35:33] <kwallace1> Hello. I have a Python script that uses a Glade .xml file to layout screen features, then I have Builder create the feature instances in the python file. So far so good. Now I'm trying to add HAL pins, with adding the line "self.hal = hal.component('lathe_bd')", but running the script returns "RTAPI: ERROR: could not open shared memory (errno=2)".
[09:37:06] <kwallace1> I assume that RTAPI needs to be loaded and running in order to create the pins. Basically, what needs to be in place in order to create HAL pins in a Python script?
[09:42:31] <jepler> is realtime running (e.g., via halrun)?
[09:42:32] <cradek> you could invoke your script with loadusr in a hal file, then use halrun to run the hal file
[09:44:47] <kwallace1> I'm only running the Python script, so I think realtime would need to be started from my script, which I haven't figured out yet.
[09:45:23] <cradek> try what I said instead of running your script directly
[09:46:33] <kwallace1> Okay, I'll give a try. Thanks.
[09:46:47] <jepler> you'll probably eventually want a hal script to do things like link pins, but you can start with: halrun loadusr -w python my-script.py
[09:47:07] <jepler> this will set up realtime, then run python my-script.py, then after it exits it will stop realtime
[09:53:37] <kwallace1> Yes, It seems to work from halrun/loadusr ... . I added some "self.hal.newpin" lines and the pins "show" up. Yay, now I can move on. Thank you.
[09:54:19] <jepler> welcome.
[09:56:13] <cradek> yay
[11:22:29] <skunkworks_> micges, I did a little more editing on the wiki
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai
[11:24:41] <micges> skunkworks_: cool, thanks
[11:25:14] <skunkworks_> zultron - this is what I had to do to build rtnet.
[11:25:16] <skunkworks_> As of 07/01/2013 to build rtnet the kernel headers need to be installed
[11:25:16] <skunkworks_> $ sudo apt-get install linux-headers-3.5.7-xenomai-2.6.2.1
[11:25:16] <skunkworks_> and a symlink pointing to them in a 'build' directory
[11:25:16] <skunkworks_> $ sudo ln -s /usr/src/linux-headers-3.5.7-xenomai-2.6.2.1/ /lib/modules/3.5.7-xenomai-2.6.2.1/build
[11:28:40] <skunkworks_> zultron, ^
[11:45:52] <memleak> Hello all, I'm on debian 7.1 squeeze and I'm getting a problem with the configuration process of linuxcnc: checking libgl1-mesa-dri workaround... test for libgl1-mesa-dri workaround failed, please file a bug
[11:46:33] <memleak> I can compile a new version of mesa without a problem, will that fix it?
[11:49:39] <memleak> I purged it from configure.in for now, not sure why it's needed. Gallium3D is working on my RadeonHD 5830 w/ hw accel
[11:57:53] <jepler> memleak: this affects some versions of ubuntu; I'm not sure which ones.
[11:57:54] <jepler> commit d21a488a9e82dd85aa17207b80e3d930afeff202
[11:57:55] <jepler> Author: Michael Haberler <git@mah.priv.at>
[11:57:55] <jepler> Date: Wed Mar 28 11:11:15 2012 +0200
[11:57:55] <jepler> configure: test for libgl1-mesa-dri bug and workaround
[11:57:57] <jepler>
[11:57:59] <jepler> see
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
[11:58:34] <jepler> I doubt a removal of the test will be accepted; an improvement of the test so that it functions properly your system (presumably finding that the workaround is not needed) would be more likely to be accepted.
[11:59:33] <jepler> the test is made by a separate shell script, scripts/test-libgl-bug.sh
[11:59:46] <jepler> run it, possibly with bash -x to see the steps as it executes them, to figure out why it goes off the rails..
[12:00:04] <jepler> mhaberler: if you read back to this, do you recall what version(s) of ubuntu are affected? any that were shipped to users by linuxcnc.org?
[12:00:12] <jepler> .. and are not fixed by ubuntu updates
[12:10:07] <cradek> looks like it was actually fixed after three years and two bogus bug-closings?
[12:10:41] <jepler> yeah but if it affects an old ubuntu maybe we care
[12:11:02] <cradek> ah I see
[12:11:20] <jepler> I think it does but it only was exposed after something added in master branch .. not sure though
[12:32:38] <memleak> bash -x showed it was just missing a header. Explains why I didn't have this problem on gentoo (its source-based meaning all .h files get installed by default)
[12:33:20] <memleak> jepler: I think header checking should be in configure script, not in a mesa bug workaround text.
[12:33:38] <memleak> last word should have been script..
[12:35:01] <memleak> Might as well have a boost_check_header.sh and does_gcc_work.sh in the scripts dir too :P
[12:41:44] <memleak> And then something terrible happened...
http://dpaste.com/1278140/
[12:42:11] <memleak> definitely cannot fix..
[12:47:03] <memleak> What magic is everyone else doing???
[13:05:57] <skunkworks_> I have only xenomai on 10.04 and 12.04
[13:07:27] <skunkworks_> my current experience is that audio doesn't play well with xenomai. (not that you need audio on a machine controller...) but it definatly seems to be hardware dependant.
[13:07:44] <memleak> The module for the sound most likely isn't loading.
[13:08:51] <memleak> I just compile what I need into the kernel, saves boot time, RAM, latency.
[13:09:13] <memleak> Without a single module I'm running a 3.8 kernel at 1.4MB
[13:09:20] <skunkworks_> I had 2 different video cards with hdmi audio - and whenever I would do a screen shot - or the 'click' when the update manager runs - the latency would spike. The onboard video - which also has hdmi - seem to play well.
[13:10:22] <memleak> Depending on your video card, radeon.audio=0 (or -1 i forget) might fix the issue
[13:10:50] <memleak> ^kernel command line string
[13:12:33] <skunkworks_> http://imagebin.org/263115
[13:12:49] <jepler> memleak: if you want to integrate it in the configure script that is fine too.
[13:17:00] <jepler> memleak: as for your other message, it's probably related to this bit of the rule for making rtlib/%.so:
[13:17:03] <jepler> @if ! $(IS_POWERPC); then objcopy -G __i686.get_pc_thunk.bx `xargs -r0n1 echo -G < objects/$*.exp | grep -ve '^-G $$' | sort -u` objects/$*.tmp; fi
[13:17:16] <jepler> for some reason your system uses __x86.get_pc_thunk.bx
[13:17:37] <memleak> its just debian 7.1 :/
[13:20:34] <jepler> I haven't tested on any 32-bit systems that new. Maybe gcc renamed this symbol somewhere along the line
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00248.html
[13:21:36] <memleak> So what's a good way to fix it?
[13:21:51] <memleak> Hardcoding the makefile will work for me personally..
[13:24:56] <jepler> please try with
http://emergent.unpythonic.net/files/sandbox/0001-build-gcc-changed-a-symbol-name-out-from-under-us.patch
[13:26:54] <memleak> worked!
[13:27:41] <jepler> cradek: ^^^ for 2.5 or for master? I believe it's low impact (only affects sim, tests OK on an affected system and an unaffected system)
[13:30:59] <cradek> man objcopy doesn't explicitly say it's OK if the -G names are not found. do you have enough of a feel for it to say it's fine to just add another to the list like that?
[13:31:22] <jepler> cradek: I feel OK about it because I tested on a system where I know __x86.get_pc_thunk.bx is not a symbol that exists
[13:31:33] <jepler> (i.e., the "unaffected system")
[13:32:30] <cradek> I think that's safe for 2.5 then
[13:32:57] <memleak> 2.5 is still supported?
[13:33:08] <jepler> it's the stable release version
[13:33:32] <memleak> and thats before all the xenomai / preempt_rt stuff right?
[13:33:48] <jepler> yes, the new rtos stuff is not in master for that matter.
[13:34:14] <memleak> any idea if a 3.8 rtai kernel could work with 2.5 branch?
[13:34:34] <jepler> I have no personal experience with that.
[13:35:33] <jepler> oh my patch is probably incomplete; it doesn't touch Makefile.skel or whatever it's called, the one for building standalone modules.
[13:35:39] <ssi> memleak: yea I think mhaberler is working on that
[13:35:43] <jepler> .modinc
[13:36:01] <jepler> hm the objcopy steps are not in there at all. how odd.
[13:36:33] <memleak> ssi: working on what?
[13:36:38] <memleak> 3.8 for 2.5?
[13:36:40] <ssi> yes
[13:36:45] <memleak> sweet!
[13:36:47] <ssi> er, not rtai though... xenomai
[13:36:58] <memleak> Oh..
[13:37:02] <ssi> sorry
[13:37:14] <memleak> I have two extremes, RTAI and PREEMPT_RT
[13:37:40] <memleak> Lars is getting close to solving the pagefaults
[13:38:37] <memleak> emailed me late last night, he's going to get latency-test to generate a core dump to fix up the page handler in RTAPI
[13:43:44] <jepler> (besides the RTLD_NOW issue) each piece of evidence that there are page faults I've chased down turns out to be a false positive. I most rcently noticed that getrusage uses RUSAGE_SELF, not RUSAGE_THREAD, so page faults from the non-realtime main thread of rtapi_app are reported. those pagefaults are expected. (if rt-preempt's model is such that the no thread in the process may page fault, then that's a bigger problem)
[13:55:30] <zultron> Thanks, skunkworks_ . I'll investigate why that link wasn't in the packages.
[13:59:01] <skunkworks_> zultron, I remember seeing an error a long time ago when playing with the xenomai during the install that the buld directory could not be read and will be deleted or soemthing like that..
[14:00:50] <skunkworks_> this is close to it...
[14:00:52] <skunkworks_> this is close to it...[17:58:15] <skunkworks> It seems like there should be a sym link to that directory but I seem to recall getting this
[14:00:53] <skunkworks_> [17:58:20] <skunkworks> Hmm. There is a symbolic link /lib/modules/3.5.7-xenomai-2.6.2.1/build
[14:00:53] <skunkworks_> [17:58:20] <skunkworks> However, I can not read it: Нет такого файла или каталога
[14:00:53] <skunkworks_> [17:58:20] <skunkworks> Therefore, I am deleting /lib/modules/3.5.7-xenomai-2.6.2.1/build
[14:01:26] <zultron> Whah? Where'd you get that from?
[14:01:52] <skunkworks_> it was on a russian site.. but similar to what I remember getting :)
[14:02:04] <skunkworks_> let me see if I can find the actual link
[14:02:30] <zultron> Did you delete your link?
[14:02:31] <skunkworks_> http://translate.google.com/translate?hl=en&sl=ru&u=http://www.cnc-club.ru/forum/viewtopic.php%3Ft%3D2827%26p%3D60857&prev=/search%3Fq%3D/lib/modules/3.5.7-xenomai-2.6.2.1/build%2Bsymbolic%2Blink%26client%3Dfirefox-a%26hs%3DpPv%26rls%3Dorg.mozilla:en-US:official%26biw%3D1600%26bih%3D791
[14:02:43] <zultron> Like the Russian did?
[14:02:43] <skunkworks_> they are actually talking about building rtnet.
[14:02:58] <skunkworks_> for the 7i80
[14:03:05] <zultron> I understand.
[14:03:17] <zultron> Did you follow that advice and remove the link, too?
[14:03:55] <skunkworks_> no - I just created the symlink that I posted above. there was no build link in my install
[14:04:33] <zultron> Alright, then maybe there's a problem with my packages. Just making sure you didn't zap it at some point. :)
[14:04:58] <skunkworks_> this /lib/modules/3.5.7-xenomai-2.6.2.1/build did not exist until I created it linking to the header
[14:05:33] <skunkworks_> not that I know of. And I had to do this also on 10.04 to get rtnet to build
[14:06:18] <zultron> Yep, sounds like a problem if it's missing from my packages. My new universal build branch looks for that link, too.
[14:07:12] <zultron> Thanks for the report. Gotta run....
[14:07:30] <skunkworks_> Thanks for the work on this - the install is painless
[14:09:45] <memleak> skunkworks_, make modules_install creates the symlinks.
[14:10:28] <memleak> you can even rm -rf /lib/modules and it will re-create all of that stuff.
[14:11:15] <jepler> that does not seem like good advice
[14:11:57] <jepler> lots of files in /lib/modules on an ubuntu system are installed there by the package manager
[14:12:04] <jepler> it will not "re-create all of that stuff"
[14:12:14] <memleak> well if you run multiple kernels its terrible advice unless you re-run make modules_install within every kernel tree
[14:13:26] <jepler> it's terrible advice for anyone who doesn't understand why it's terrible advice
[14:13:45] <memleak> jepler: it installs all compiled modules that were selected to build the bzImage
[14:15:42] <memleak> I'm not much of an ubuntu expert though, maybe ubuntu keeps other things in /lib/modules for nonsensical reasons.
[14:16:15] <memleak> boot loader, firefox, gnome, etc, wouldn't put it past them
[14:18:12] <jepler> any directory with package-manager installed files should not be rm -rf'd. you'll break all those packages.
[14:20:02] <memleak> Wasn't aware of that.. I'm too used to slackware and gentoo and do things the old fashioned way, my apologies.
[14:20:23] <cradek> yeah that's not an ubuntu thing, that's a "files are installed as parts of packages" thing
[14:22:44] <memleak> hey skunkworks_ i think our glxgears scores are the same because VSYNC is on..
[14:23:43] <jepler> glxgears is not a benchmark. doesn't it even admonish you to that effect these days?
[14:23:53] <memleak> not sure, could be just really bad hardware that can only render at coincidentally the same speed as the vfresh rate
[14:24:30] * memleak is being silly
[14:25:59] <skunkworks_> No cule
[14:26:03] <skunkworks_> clue even
[14:26:27] <skunkworks_> It is one of the amd apu systems
[14:29:01] <memleak> 24114 frames in 5.0 seconds = 4821.296 FPS I WIN!
[14:29:42] <memleak> hey jepler your patch fixed the issue btw, not sure if i said anything before about it..
[14:30:09] <KGB-linuxcnc> 03jepler 05v2.5_branch 52ae71f 06linuxcnc 10src/Makefile * build: gcc(?) changed a symbol name out from under us
[14:30:19] <memleak> there we go :D
[15:04:50] <kwallace2> I need another hint. I have a HAL file that sets up a 6i25. I invoke "halrun -I -f lathe_bd.hal" to set up the pins and parameters. While in the halcmd shell(?), I add "loadusr ./lathe_board_test_ui.py", "net chg_pump_enable lathe_bd.charge_pump hm2_5i25.0.pwmgen.00.enable", "start". My UI loads, the pins connect to the signal, finally start gets the thread going... everything is wonderful.
[15:08:00] <kwallace2> If I put the last three lines into the .hal file, I get am error about the UI pin not existing, which I expect, so I add "-W" to wait for the UI to load before trying the pin connection. What I get is a bunch of dots while waiting .................... but my UI does show up on the screen.
[15:09:38] <jepler> you have to use -Wn name
[15:09:43] <cradek> man halcmd, search for loadusr, try whichever wait is appropriate
[15:09:44] <jepler> where name is the name of the component your program creates
[15:15:22] <kwallace2> The .py file I am loading uses Builder and has the handlers for the buttons and that's it. It's not what I am used to calling a "component", nor do I know how to name it. Will using -Wn instead of -W make a difference?
[15:16:05] <jepler> if it creates pins it is a hal component and has a hal component name that will be shown by 'halcmd show comp'
[15:22:08] <KGB-linuxcnc> 03seb 05master 62d9994 06linuxcnc 10docs/src/common/GPLD_Copyright.txt * docs: update copyright for 2013
[15:22:08] <KGB-linuxcnc> 03seb 05master 85539c2 06linuxcnc 10docs/src/Master_Developer.txt * docs: clean up Developer's Manual pdf
[15:22:10] <KGB-linuxcnc> 03jmkasunich 05master 2b0624c 06linuxcnc 10docs/man/man9/sampler.9 * remove outdated man page info
[15:22:17] <KGB-linuxcnc> 03jmkasunich 05master 0fde057 06linuxcnc 10src/hal/components/clarkeinv.comp * allow clarkeinv to rotate the vector
[15:22:23] <KGB-linuxcnc> 03jmkasunich 05master 02d22d6 06linuxcnc 10docs/man/man9/motion.9 10src/emc/motion/motion.c * allow for floating point in the base thread
[15:22:29] <KGB-linuxcnc> 03jmkasunich 05master 27f474a 06linuxcnc 10lib/python/pyvcp_widgets.py * pyvcp dial widget: fix various odd behaviors
[15:22:36] <KGB-linuxcnc> 03dgarrett 05master 378cc91 06linuxcnc 10scripts/sim_pin * sim_pin: support u32,s32,float pin,param types
[15:22:42] <KGB-linuxcnc> 03Kim 05master db8ebf6 06linuxcnc 10docs/src/code/Code_Notes.txt * Docs: update an outdated paragraph
[15:22:48] <KGB-linuxcnc> 03jepler 05master 52ae71f 06linuxcnc 10src/Makefile * build: gcc(?) changed a symbol name out from under us
[15:22:55] <KGB-linuxcnc> 03jepler 05master e6f1591 06linuxcnc 10tests/ 10(12 files in 2 dirs) * New tests (currently failing in sim)
[15:23:01] <KGB-linuxcnc> 03jepler 05master 4e6be75 06linuxcnc 10src/Makefile.modinc.in * build: use $(Q) to quiet external module building
[15:23:07] <KGB-linuxcnc> 03jepler 05master 9c590e5 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in 04tests/symbols.1/xfail * sim: only keep exported symbols in .so files
[15:23:14] <KGB-linuxcnc> 03jepler 05master 6010e15 06linuxcnc 10src/rtapi/sim_rtapi_app.cc 04tests/symbols.0/xfail * sim: Bind all symbols at load time
[15:23:21] <KGB-linuxcnc> 03jepler 05master 5dabf50 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * sim: don't export symbols from sim_rtapi_app to components
[15:23:27] <KGB-linuxcnc> 03jepler 05master eaeed64 06linuxcnc 10docs/man/man9/motion.9 10src/Makefile 10src/emc/motion/motion.c * Merge remote branch 'origin/v2.5_branch'
[15:23:35] <KGB-linuxcnc> 03jepler 05master fcd63da 06linuxcnc 10src/Makefile.modinc.in * propagate Makefile changes to Makefile.modinc
[15:29:07] <kwallace2> I did "show comp" before and after "loadusr ./lathe_board_test_ui.py" and the difference was a line "8 User lathe_bd 5826 initializing". "lathe_bd" seems to be from the original .hal file called with "halrun" ( halrun -I -f lathe_bd.hal ). I tried "loadusr -Wn lathe_bd ./lathe_board_test_ui.py" even though the name seems wrong to me, and got the dots.
[15:30:15] <linuxcnc-build> build #1133 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1133 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:30:15] <linuxcnc-build> build #1130 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1130 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:34:12] <jepler> (a timeout in the linuxcncrsh test, which I don't think I touched...)
[15:41:36] <kwallace2> Oops, I think I found where the UI name is set and it is the same as the hardware .hal file.
[15:45:11] <jepler> linuxcnc-build: force build --branch=v2.5_branch checkin
[15:45:22] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[16:10:35] <kwallace2> Adding "self.hal.ready()" to the UI .py _init_ section seems to have fixed it, imagine that. :)
[16:10:57] <jepler> oh yeah I should have picked up on "initializing" in that halcmd output but I didn't..
[16:14:11] <kwallace2> I should have posted the my source. I found the line in JT's tutorial samples and it looked like what I needed. Thank you again for the help, Thanks JT if you are out there. Now, on to find another corner to paint my self into.
[16:17:17] <kwallace2> That actually happened when I was a kid paining my Dad's garage floor as he watched and didn't say a word. Though that wasn't as bad as when he told me to pull the spark plug wire on a running lawnmower engine.
[16:22:32] <linuxcnc-build> build #1134 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1134 blamelist: Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Jeff Epler <jepler@dsndata.com>, John Kasunich <jmkasunich@fastmail.fm>, Sebastian Kuzminsky
[16:22:32] <linuxcnc-build> <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[16:24:43] <linuxcnc-build> build #334 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/334 blamelist: Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Jeff Epler <jepler@dsndata.com>, John Kasunich <jmkasunich@fastmail.fm>,
[16:24:43] <linuxcnc-build> Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[16:25:57] <JT-Shop> kwallace2: have fun painting
[16:31:57] <linuxcnc-build> build #1133 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1133 blamelist: Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Jeff Epler <jepler@dsndata.com>, John Kasunich <jmkasunich@fastmail.fm>, Sebastian
[16:31:57] <linuxcnc-build> Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[16:32:18] <linuxcnc-build> build #1133 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1133 blamelist: Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Jeff Epler <jepler@dsndata.com>, John Kasunich <jmkasunich@fastmail.fm>, Sebastian
[16:32:18] <linuxcnc-build> Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[16:33:54] <linuxcnc-build> build #1131 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1131 blamelist: Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Jeff Epler <jepler@dsndata.com>, John Kasunich <jmkasunich@fastmail.fm>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett
[16:33:54] <linuxcnc-build> <dgarrett@panix.com>
[16:33:55] <linuxcnc-build> build forced [ETA 1h45m05s]
[16:33:55] <linuxcnc-build> I'll give a shout when the build finishes
[16:35:35] <memleak> jepler: does using mlocked pages in latency-test seem silly if RTAPI is already using them?
[16:41:00] <KGB-linuxcnc> 03jepler 05master 9ed3195 06linuxcnc 10scripts/halrun.in * halrun: provide HAL_RTMOD_DIR just as linuxcnc wrapper script does
[16:41:00] <KGB-linuxcnc> 03jepler 05master ee0811f 06linuxcnc 10tests/symbols.0/checkresult * fix results checker for module-based builds
[16:41:12] <jepler> memleak: if the manpage for mlockall() can be taken at face value then all subsequent allocations will be locked too, up to the locked memory limit
[16:41:20] <jepler> beyond the locked memory limit, an error should be issued
[16:41:31] <jepler> .. by mmap() or sbrk()
[16:41:52] <jepler> but I only know what the manpage says, not whether the implementation conforms
[16:44:40] <memleak> ....did I really just fix the page fault issue....
[16:46:32] <memleak> ulimit -c 40000 are you serious?
[16:46:41] <memleak> you're that simple.. omg WOW WASTE OF TIME
[16:47:48] <memleak> epic bloody facepalm. latency is under 10000 ns sustained
[16:49:26] <memleak> not anymore..
[16:50:09] <memleak> linuxcnc finally runs though without an issue as long as you dont switch ttys, then a pagefault occurs
[17:00:35] <memleak> it sure does make it perform differently though!
[17:01:08] <jepler> why would switching ttys cause a page fault in a realtime thread?
[17:01:19] <jepler> that doesn't make any sense
[17:01:28] <memleak> no idea.
[17:02:06] <memleak> page faults are worse now though when they actually do happen however..
[17:02:23] <memleak> (or if the monitor falls asleep or you open up firefox apparently too)
[17:02:58] <memleak> seem to not do it while idling though..
[17:14:17] <linuxcnc-build> build #1135 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1135
[17:25:26] <linuxcnc-build> build #1132 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1132
[17:45:39] <skunkworks> memleak: sounds like classic video interaction with realtime
[17:48:02] <memleak> skunkworks, definitely not, its consistent with every single person whos trying to get PREEMPT_RT working with LinuxCNC
[17:48:18] <memleak> regardless of GPU and Xorg drivers.
[17:48:23] <skunkworks> ah
[17:48:52] <memleak> if only it was that easy though! :)
[17:55:10] <skunkworks> did you look at the mailing list? there was someone trying to get preemt running - I remember the memory allocation being one issue..
[17:55:44] <memleak> lars segerlund is working on it with me
[17:57:22] <memleak> zultron apparently has Xenomai working without page faults and low latency times, not sure exactly what he did though.
[17:58:30] <memleak> rtos-integration-preview3-merged-into-master and rtos-master-v0 both have issues with Xenomai for me. just as bad latency as PREEMPT_RT
[18:00:22] <memleak> There's this autobuilder he wrote but a script that just does all the work for me doesn't really help much if I can't re-create his steps.
[18:00:46] <memleak> Then it all just goes back to "use the linuxcnc live cd and don't ever touch anything" philosophy.
[18:03:30] <zultron> memleak, I recall reading something about the text consoles interfering with RT performance. It said something about going as far as to never write anything to the console so that it's never initialized; redirect console output to serial or something. It said X windows isn't a problem.
[18:04:04] <zultron> Don't remember anything about where I saw that, sorry.
[18:04:23] <memleak> zultron, does your autobuild script / tree have any source changes to linuxcnc?
[18:04:44] <memleak> the directory structure of everything is very obscure, i'm digging through it and can't really figure out what's going on.
[18:05:04] <zultron> Very few source changes
[18:05:29] <zultron> Certainly doesn't change directory structure....
[18:05:56] <memleak> I meant the directory structure of the build script you wrote itself.
[18:06:20] <zultron> What build script? Maybe I don't understand something.
[18:06:35] <memleak> https://github.com/zultron/debian-linuxcnc-autobuild
[18:07:07] <zultron> Ah. Main important files are Makefile and pbuild/pbuilderrc. Actually quite simple....
[18:07:21] <memleak> Oh..
[18:07:55] <memleak> a lot of the stuff in the "git" folder really confused me, heh
[18:08:26] <zultron> It does check out a few git submodules, but those aren't part of that git tree.
[18:09:06] <linuxcnc-build> build #1136 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1136 blamelist: Jeff Epler <jepler@unpythonic.net>
[18:09:40] <memleak> Where are the changes you made to the linuxcnc tree that aren't upstream (yet?)
[18:10:13] <zultron> The autobuilder stuff doesn't directly have anything to do with LinuxCNC. It simply builds Xenomai kernels and runtime libs.
[18:10:41] <zultron> ... into Debian packages, of course.
[18:15:38] <memleak> I'm going to try idle=poll in PREEMPT_RT brb
[18:20:43] <memleak> that seemed to have fixed the "page faults"
[18:21:17] <memleak> switch TTYs, its fine..
[18:22:00] <memleak> is it ok for the max interval (not the jitter) to be around 1,000,000 ?
[18:22:14] <memleak> ^servo thread
[18:24:18] <memleak> Who knows of a really good way to put as much stress on the latency test as possible? cpu burn-in utilities? terribly written website in java?
[18:24:54] <memleak> I wonder if this issue is really gone and if it won't come back.. it never lasted this long before..
[18:26:25] <linuxcnc-build> build #1133 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1133 blamelist: Jeff Epler <jepler@unpythonic.net>
[18:29:39] <memleak> skunkworks, was that you that recommended idle=poll on the kernel command line? if so, thanks!
[18:29:56] <memleak> might have been like a week or two ago..
[18:55:25] <memleak> new kernel, brb
[19:00:38] <skunkworks> memleak: yes - for xnomai it really helped
[19:29:58] <skunkworks> our machines accelleration is a bit on the low side - so we didn't need the lowpass.
[19:30:00] <skunkworks> memleak: yes - for xnomai it really helped
[19:32:38] <memleak> I told lars about it and how it affected PREEMPT_RT performance as well
[19:33:06] <memleak> I'm testing it on a different system now too.
[19:37:39] <memleak> :/ doesn't work on the other box so far..
[19:38:42] <memleak> grrrrrrrrrrr
[19:41:06] <zultron> memleak, perhaps you should consider reading the docs? That's in the tutorial I wrote:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages#Latency_spikes
[19:42:30] <memleak> zultron: the fix for the page fault / latency issue I have, nobody can figure out yet.
[19:42:52] <memleak> If it was that obvious I wouldn't be here ;)
[19:43:38] <memleak> It's for every person that tries to get PREEMPT_RT working that there is weird latency spikes.
[19:43:57] <memleak> Not even the devs who wrote it can figure out what is wrong yet, but one man... Hopefully he will!
[19:45:05] <memleak> He's using ftrace to determine exactly where the latency problem is coming from, then looking at the core dump with gdb
[19:46:46] <memleak> zultron, if you'd like to help us figure out what's wrong, fire up a PREEMPT_RT kernel when you can and just build linuxcnc as usual with the rtos branch, run linuxcnc and watch the possibly false positive page fault errors emerge!
[19:51:43] <memleak> rtapi_wait_hook in rt-preempt-user.c
[19:54:14] <memleak> Could be an issue with sim_rtapi_app.cc Nobody knows yet for sure.
[19:54:41] <memleak> zultron, I'll be AFK for the rest of the night, if you need me for anything just ping CaptHindsight