Back
[00:00:21] <mhaberler> the suggestion was not to do it in the gui
[00:01:55] -!- mhaberler has quit [Quit: mhaberler]
[00:11:46] <cradek> mhaberler: the question and cmorley's comments both were talking about one gui. I was not responding to your suggestion at all.
[00:23:00] -!- gammax has quit [Ping timeout: 258 seconds]
[00:36:02] -!- andypugh has quit [Quit: andypugh]
[00:49:15] -!- PetefromTn has quit [Remote host closed the connection]
[00:50:19] -!- zzolo has quit [Quit: zzolo]
[00:56:34] -!- asdfasd has quit [Ping timeout: 256 seconds]
[00:58:18] -!- rob_h has quit [Ping timeout: 264 seconds]
[01:00:12] -!- gammax has quit [Changing host]
[01:09:29] -!- skunkworks has quit [Remote host closed the connection]
[01:10:56] -!- phantoxeD has quit [Ping timeout: 260 seconds]
[01:11:18] -!- adb has quit [Ping timeout: 276 seconds]
[01:14:18] -!- dr00bie has quit [Ping timeout: 245 seconds]
[01:22:32] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:39:39] gimpspace is now known as gimpswork
[01:45:33] -!- gammax has quit [Read error: Connection reset by peer]
[01:46:07] -!- gammax has quit [Changing host]
[02:09:34] -!- ravenlock has quit [Ping timeout: 258 seconds]
[02:16:40] s1dev is now known as Hoggymus
[02:16:50] Hoggymus is now known as Hoggymus_Prime
[02:18:45] Hoggymus_Prime is now known as Hoggy
[02:19:07] Hoggy is now known as Hoggymus_Prime
[02:20:15] Hoggymus_Prime is now known as Hoggy
[02:20:36] Hoggy is now known as s1dev
[02:25:47] <seb_kuzminsky> new version of rtai 3.9.1 on linux 3.5.7
[02:25:57] <seb_kuzminsky> debs are here:
http://highlab.com/~seb/linuxcnc/rtai-for-3.5-prerelease/
[02:26:25] <seb_kuzminsky> my rtai branch is here:
https://github.com/SebKuzminsky/rtai/commits/prerelease-4
[02:26:36] <seb_kuzminsky> and the linux branch is here:
https://github.com/SebKuzminsky/linux-stable/commits/linux-3.5-rtai-4
[02:26:44] * seb_kuzminsky goes off to test...
[02:29:05] <skunkworks> seb_kuzminsky: what is new?
[02:30:25] -!- Tom_L has quit []
[02:33:34] -!- pjm_ has quit [Read error: Connection reset by peer]
[02:36:20] <seb_kuzminsky> some bugfixes in upstream rtai
[02:36:39] <seb_kuzminsky> i'm not really sure, and their cvs server is down so i can't see the project history...
[02:49:39] <seb_kuzminsky> well here's something new: a new bug in rtai that prevents linuxcnc from compiling :-/
[03:03:10] -!- Keknom has quit [Quit: Leaving.]
[03:03:14] -!- pfred1 has quit [Quit: ..]
[03:25:46] -!- cmorley [cmorley!~chris@d75-159-114-68.abhsia.telus.net] has joined #linuxcnc-devel
[03:32:49] <seb_kuzminsky> i put an updated rtai-modules deb on highlab that fixes the compile problem
[03:38:20] -!- Valen has quit [Quit: Leaving.]
[04:08:03] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[04:23:03] -!- ProxDem has quit [Ping timeout: 276 seconds]
[04:38:02] <seb_kuzminsky> cradek: i want to put the three new rtos kernel debs in the linuxcnc.org debian archive soon
[04:40:57] -!- PetefromTn has quit [Remote host closed the connection]
[04:43:35] -!- FinboySlick has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
[04:57:21] <seb_kuzminsky> i just started the new rtai kernel on a test machine with a 5i20 and *no* motors or bridgeports plugged in to it
[04:57:44] -!- kwallace [kwallace!~kwallace@smb-87.sonnet.com] has parted #linuxcnc-devel
[04:57:55] <seb_kuzminsky> when i ran linuxcnc 2.5, while the machine was still in estop, the feedback positions of all three axes ran away
[04:58:06] <seb_kuzminsky> this is with the hm2-stepper config
[04:59:10] <seb_kuzminsky> https://lh3.ggpht.com/_qGe_7zzbXtk/SteidAfzSII/AAAAAAAAAb4/DijayaV9GXc/s1600/le+sigh.jpg
[04:59:39] <seb_kuzminsky> it passed a full runtests, and the latency-test numbers looked fine
[04:59:47] <seb_kuzminsky> ugh, a debugging problem for another night
[05:00:43] -!- Felix29 has quit []
[05:01:05] <seb_kuzminsky> btw, this is exactly like the servo runaway i had on my bridgeport with an earlier version of rtai 3.9 on linux 3.5.7
[05:01:15] -!- nazarm has quit [Quit: nazarm]
[05:02:34] -!- Fox_Muldr has quit [Ping timeout: 256 seconds]
[05:06:49] -!- cmorley has quit [Ping timeout: 256 seconds]
[05:07:51] <seb_kuzminsky> same hardware ran fine on lucid+rtai (just like my bp does)
[05:28:30] -!- jpk has quit [Ping timeout: 258 seconds]
[05:29:37] -!- capricorn_1 has quit [Read error: Connection reset by peer]
[05:50:21] <mhaberler> Jeff - could I ask you to read over
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/interp-exit-hook - the intent is to regularize interpreter startup anx exit Python hooks
[05:51:43] frewsxcv94709 is now known as frewsxcv
[05:52:03] <mhaberler> there is a missing piece, namely calling interp.exit() from gcodemodule.cc such that the Python environment is still intact, which denies the use of Py_Atexit() as I understand it; it is not terribly important to have __delete__() called from UI interp instances but for regularity/minimum surprise reasons I'd like to have that done too
[05:53:05] <mhaberler> the use case is saving/restoring any state in a user-defined fashion beyond what Interp::save_parameters can do
[06:00:25] <mhaberler> if nothing else, the python atexit module is a fix too
[06:14:04] -!- jfire has quit [Quit: Leaving.]
[06:18:49] -!- ve7it has quit [Remote host closed the connection]
[06:47:33] -!- fomox has quit [Ping timeout: 248 seconds]
[06:53:56] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[07:05:03] -!- mhaberler has quit [Quit: mhaberler]
[07:08:37] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:24:55] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[07:40:14] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[07:55:14] -!- emel has quit [Excess Flood]
[07:56:02] -!- b_b has quit [Changing host]
[07:58:37] -!- i_tarzan has quit [Quit: leaving]
[08:23:46] -!- rob_h [rob_h!~rob_h@2.124.22.160] has joined #linuxcnc-devel
[08:56:40] -!- emel has quit [Excess Flood]
[09:06:05] Cylly is now known as Loetmichel
[09:07:49] -!- dhoovie has quit [Read error: Connection reset by peer]
[09:17:03] -!- pingufan has quit [Quit: Konversation terminated!]
[09:44:17] -!- mhaberler has quit [Quit: mhaberler]
[10:06:23] -!- syyl has quit [Read error: Connection reset by peer]
[10:07:04] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[10:26:34] -!- b_b has quit [Changing host]
[10:38:22] -!- gammax has quit [Ping timeout: 246 seconds]
[10:47:03] -!- emel has quit [Excess Flood]
[10:55:27] -!- skunkworks has quit [Remote host closed the connection]
[11:27:28] -!- emel has quit [Excess Flood]
[11:30:35] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:31:04] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:37:16] -!- sumpfralle has quit [Read error: Connection reset by peer]
[11:40:28] -!- Valen1 has quit [Quit: Leaving.]
[11:45:13] -!- UncleG has quit [Quit: Page closed]
[11:46:25] -!- emel has quit [Excess Flood]
[11:46:52] -!- zlog has quit [Remote host closed the connection]
[11:46:56] -!- Tom_itx has quit []
[11:55:30] -!- dhoovie has quit [Read error: Connection reset by peer]
[11:56:05] <jepler> mhaberler: do not use __double_underscore__ names for anything of your own invention.
[11:56:19] <mhaberler> ok
[11:56:24] <jepler> though I see that this practice is already widespread in those files, so forget it
[11:56:49] <mhaberler> need to look for others, not sure otoh
[11:57:18] <mhaberler> I assume __ is reserved for Python magic?
[11:58:15] <jepler> right
[11:59:15] <mhaberler> doesnt look that wild, will rename
[11:59:34] <mhaberler> any suggestion for the exit handler in gcodemodule.cc?
[11:59:43] -!- cmorley [cmorley!~chris@blk-252-45-101.eastlink.ca] has joined #linuxcnc-devel
[11:59:45] <mhaberler> it's a bit academic though
[12:01:11] <mhaberler> most of the __init__() methods are in fact wrapper class instantiations, so I plea thats not totally wrong ;)
[12:01:54] <jepler> it looks simple enough
[12:02:03] <jepler> DELETE_FUNC must have been declared before the first commit in this topic?
[12:02:16] <mhaberler> nope
[12:02:39] <jepler> oh there's it's addition
[12:02:48] <mhaberler> http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/emc/rs274ngc/interp_internal.hh;h=ff92d600f86cfc4b396602aa7a8346f37dfe986e;hb=3bf45854ddaa8062c86d7c18d14bf6714f202433#l732
[12:03:38] <jepler> what fills out savedError? could it be a member of Interp instead of a file-level static?
[12:03:48] -!- gimpswork has quit [Ping timeout: 264 seconds]
[12:04:00] <mhaberler> hm, need to check, that might be a bug
[12:04:43] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[12:04:54] <mhaberler> it is a bit useless because things are so far down the shutdown at this point there isnt much left to do with them except write to stderr
[12:06:06] <mhaberler> ERM fills out savedError
[12:06:43] <mhaberler> see interp_internal.h
[12:07:18] <mhaberler> I think it should be a member.. eventually
[12:07:55] <jepler> at this point, would PyErr_Occurred() be false?
[12:07:56] <jepler> + if (python_plugin->plugin_status() == PLUGIN_EXCEPTION) {
[12:08:06] <jepler> if it was true, you could skip all that and just PyErr_WriteUnraisable()
[12:08:22] <jepler> but I'm guessing from the way this is written, the pending Python exception has been cleared
[12:08:33] <mhaberler> right
[12:08:44] <mhaberler> I dont propagate them out of the plugin
[12:09:37] <jepler> and savedError is in v2.5_branch so that's not your doing either
[12:09:49] <jepler> it looks fine
[12:10:01] <mhaberler> that goes way back
[12:11:05] -!- Felix [Felix!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[12:12:45] <mhaberler> can I have your ear on another question for a few minutes?
[12:13:13] <jepler> go ahead
[12:13:14] <mhaberler> I've done a little experiment to normalize shared memory usage across all thread flavors
[12:13:44] <mhaberler> intent is to have a single flavor of shm to enable cross-linking of HAL instances
[12:14:02] <mhaberler> (that works only if all shm segments are the same regardless of flavor)
[12:14:36] <jepler> "the same" = "allocated by the same API"?
[12:14:39] <mhaberler> the userland flavors use mmap() in this case; in case of an additional kernel flavor
[12:14:48] <mhaberler> the same API, yes, sorry
[12:15:10] <mhaberler> for instance you cant cross-attach from a posix instance into rtai or xeno-kernel shm and vice versa
[12:16:09] <mhaberler> I've cooked up a kernel shm char driver to cover the mmap() case for rtai+xeno-kernel, and that works fine (it also gets rid of the 'rt must start before uslapi) restriction on kernel flavors)
[12:16:33] <mhaberler> my observation is mmap is much less bloated than sysvipc
[12:16:49] <mhaberler> and also more robush in terms of crashes - no shmsegs hanging around
[12:17:11] <mhaberler> so I'm considering to dump sysvipc for userland styles and go all mmap()
[12:17:47] <mhaberler> I see no downsides yet, do you see any? afaict sysvipc shm is done with mmap support in-kernel to start with
[12:18:20] <jepler> I don't know much about this
[12:18:24] <mhaberler> ah, ok
[12:18:30] <jepler> it sounds like you've investigated more than I have
[12:18:33] <mhaberler> discharged in honor ;)
[12:19:20] <jepler> my first concern was pretty much dismissed by what you said: in the case of rtai, is the realtime guarantee of userspace mmap strong enough .. but if the memory is actually backed by some special device that uses rtai apis then presumably yes it is
[12:20:04] <mhaberler> I sill have to cross-check it against rtai_shm.c and the xenomai equivalent, but I have Paolo's nod
[12:21:11] <mhaberler> a last one.. when you wrote sim_rtapi_app.cc, you removed the rtapi_data shm segment; I have found that causes some hoops to jump pn the ulapi side because of reduced visibility; I'm considering reintroducing it as bona-fide shm segment because it gets rid of some irregularities
[12:22:09] <mhaberler> (for instance module refcounting is such a wart)
[12:22:25] <jepler> that's fine. It's too long ago to remember that decision
[12:22:30] <mhaberler> you dont see the allocation bitmap in ulapi
[12:22:36] <mhaberler> fair enough
[12:23:12] <mhaberler> the idea is to have this in halcmd:
[12:23:36] <mhaberler> attach 23 foo # 23 is an instance id, foo is the instance symbolic name
[12:23:51] <mhaberler> net signame foo:comp.pin
[12:24:33] <mhaberler> for pins, signals and HAL queues for now; this should take care of basic multi-instance synchronisation at the HAL layer, for instance for multi-spindle
[12:24:48] <jepler> now you have lost me
[12:25:17] <jepler> this is about multiple running hals?
[12:25:17] <mhaberler> consider a multi-spindle machine, each spindle controlled by a linuxcnc instance
[12:25:32] <mhaberler> yes, that works already (the video I posted a while ago)
[12:25:45] <mhaberler> but you cant cross-link pins across instances
[12:25:50] <mhaberler> as of now, that is
[12:26:21] <mhaberler> the most obvious solution is to make some pins or signals appear in other instance HAL namespaces
[12:26:52] <mhaberler> (there is dangling reference prevention in place; refcounting)
[12:28:01] <jepler> what happens when this session exits but foo:comp.pin is written because the foo session is still active?
[12:28:28] <mhaberler> the removal of the HAL shm segment is put on hold until refcount drops to 0
[12:28:53] <mhaberler> (in that case sysvipc actually would be an advantage ;)
[12:29:33] <jepler> will there be a single hal lock across all instances, so that 'net signame foo:comp.pin' can't race with another net or unlinkp operation done from the viewpoint of instance foo?
[12:30:22] <jepler> I also wonder how SHMPTR / SHMOFF will work .. but if they don't you'll know it
[12:30:32] <mhaberler> nope, those need twisting
[12:31:27] <mhaberler> good point, I'm not there yet as I was held up with this shm thing, but I think both mutexes need to be held, and the catch is that the locking may not create a cycle, but I have find a way to do this
[12:32:14] <mhaberler> current plan is to lock in instance sequence ordering which is globally known and the same everywhere
[12:32:25] <jepler> you could also look into whether you can make anything that might be operating cross-instance use compare-and-swap type operations
[12:32:56] <jepler> hm but you still need to have a lock in the other instance to do the search for pin operation
[12:33:12] <mhaberler> yes, thats not enough, you need to lock the name dicts
[12:33:16] <mhaberler> (lists)
[12:33:16] <jepler> I need to head in to work. good luck on all your projects..
[12:33:21] <mhaberler> sure
[12:33:38] <mhaberler> rtapi_bitops is on my list; actually I was planning to work on it to move it to gcc generics for mbarriers and CAS type ops
[12:34:09] <mhaberler> luckily Charles is quite knowledgeable on such lowlevel architecture dependent stugg
[12:34:12] <mhaberler> stuff
[12:34:13] <mhaberler> cu!
[12:35:57] <jepler> I'd be happy to see those use gcc intrinsics where possible!
[12:36:31] <mhaberler> ah, ok - well Charles looked into them doing the right thing on the relevant gcc versions and archs, and it looks good so far
[12:37:02] -!- fomox has quit [Ping timeout: 256 seconds]
[12:37:15] <mhaberler> I already use them for ARM (USE_GCC_ATOMICOPS) or so, but then this doesnt say much yet on a UP ARM board except it doesnt keel over
[12:41:11] <mhaberler> it is a _single_ project - 10 year makeover of RT+NML land ;)
[12:51:31] -!- Felix has quit []
[12:58:11] <mhaberler> btw we also need to look what llvm does on gcc intrinsics; I _think_ they are fine but not 100%
[13:09:06] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[13:14:35] -!- PetefromTn has quit [Ping timeout: 255 seconds]
[13:16:53] -!- kktherock has quit [Remote host closed the connection]
[13:17:30] -!- syyl has quit [Ping timeout: 264 seconds]
[13:40:41] -!- cmorley has quit [Ping timeout: 258 seconds]
[13:44:18] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[13:44:51] -!- stsydow has quit [Remote host closed the connection]
[13:47:58] -!- cmorley [cmorley!~chris@blk-252-45-101.eastlink.ca] has joined #linuxcnc-devel
[13:48:57] -!- psha[work] has quit [Quit: Lost terminal]
[13:58:54] -!- cmorley has quit [Ping timeout: 264 seconds]
[14:28:44] -!- kwallace [kwallace!~kwallace@smb-110.sonnet.com] has joined #linuxcnc-devel
[14:43:18] -!- mk0 has quit [Quit: Leaving]
[14:54:23] -!- zzolo has quit [Quit: zzolo]
[15:10:36] -!- jfire has quit [Client Quit]
[15:43:11] -!- mhaberler has quit [Quit: mhaberler]
[15:59:25] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[16:00:24] -!- jfire has quit [Quit: Leaving.]
[16:05:09] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:06:16] -!- fomox has quit [Ping timeout: 245 seconds]
[16:11:23] -!- Wildhoney has quit [Ping timeout: 276 seconds]
[16:12:51] -!- phantoxeD has quit [Ping timeout: 258 seconds]
[16:14:54] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[16:15:44] -!- mr_new2 has quit [Read error: Connection reset by peer]
[16:19:11] -!- fomox has quit [Ping timeout: 245 seconds]
[16:21:16] -!- V0idExp has quit [Quit: Leaving.]
[16:22:56] -!- sumpfralle1 has quit [Quit: Leaving.]
[16:26:01] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[16:30:33] -!- L84Supper has quit [Ping timeout: 240 seconds]
[16:32:31] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[16:33:39] -!- PetefromTn has quit [Ping timeout: 276 seconds]
[16:49:48] -!- ink has quit [Disconnected by services]
[16:59:33] -!- gonzo_ has quit [Ping timeout: 240 seconds]
[17:08:23] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:12:13] -!- gonzo__ has quit [Ping timeout: 240 seconds]
[17:18:24] -!- vladimirek has quit [Remote host closed the connection]
[17:25:26] -!- stsydow has quit [Remote host closed the connection]
[17:28:36] -!- Andrew_rbh has quit [Quit: Zzz]
[17:32:28] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[17:32:55] <memleak> Hello everyone! I'm trying to compile EMC but it says it cannot find boost::python shared libraries but it is already installed. Do any ubuntu users here know where the shared libraries are for boost python?
[17:37:34] <andypugh> In /usr/include/boost
[17:38:21] <memleak> wouldn't those be headers, not .so libraries?
[17:38:37] <andypugh> Now you mention it..
[17:39:01] <memleak> "cannot find boost::python shared libraries" :P
[17:39:25] <andypugh> Yeah, you were right about that just being headers.
[17:39:47] <memleak> it finds the headers for boost::python just fine!
[17:40:30] <memleak> i think i'm supposed to use --with-boost-python but i don't know what to enter..
[17:40:51] -!- PetefromTn has quit [Ping timeout: 245 seconds]
[17:41:02] <memleak> the ./configure description is terrible.
[17:41:11] <memleak> http://dpaste.com/1059427/ maybe that can help you help me?
[17:42:21] <memleak> i've tried everything from ./configure --with-boost-python=libboost_python libboost-python /usr/lib64/libboost_python-2.7.so etc etc it never finds them :/
[17:43:37] <andypugh> They appear to live in usr/lib
[17:43:54] <memleak> i use --libdir=/usr/lib64
[17:44:18] <memleak> what's the names of the shared libraries? do they look like the ones in my paste?
[17:45:19] <andypugh> Not really: libboost_python-py26.so
[17:45:56] <andypugh> libboost_python-mt-py26.so
[17:46:00] <memleak> ok i'll try and see if i can fake it out then
[17:46:15] <memleak> sed here i come :)
[17:46:39] <andypugh> http://dpaste.com/1059431/
[17:51:56] -!- bootnecklad has quit [Quit: BRB WIREWRAPPING]
[17:53:32] <memleak> thanks!
[17:53:48] -!- gammax has quit [Ping timeout: 256 seconds]
[17:55:05] <cradek> the wiki says libboost-python-dev is the package to install
[17:55:26] <memleak> for debian and ubuntu yes. this is gentoo
[17:55:39] <memleak> i think i fixed it :)
[17:55:42] <cradek> yay
[17:55:45] <seb_kuzminsky> heh, i was about to talk about debian's autodetection of missing build deps
[17:55:59] <andypugh> cradek: Did you write the Shuttlexpress compoenent?
[17:56:16] <cradek> no
[17:56:46] <memleak> yes it compiled! thanks andypugh!!!!
[17:57:19] <seb_kuzminsky> andypugh: i wrote it
[17:57:23] <andypugh> Ah, it was seb_kuzminsky
[17:57:27] <seb_kuzminsky> ;-)
[17:57:35] <jepler> It looks if your boost python lib is libboost_python-abracadabra.so then use --with-boost-python=abracadabra
[17:57:49] <jepler> .. but if so the configure help text is wrong
[17:58:01] <andypugh> Do you think it would work for the shuttle pro with a change to the device ID? (Which is apparently 0x11 for the pro)
[17:58:14] <memleak> jepler, is that to me?
[17:58:49] <seb_kuzminsky> andypugh: fiik
[17:59:07] <jepler> memleak: I thought it might help you
[17:59:34] <memleak> thanks jepler! it's a much more proper fix if that will work :)
[18:00:08] <andypugh> seb_kuzminsky: There is a chap on the forum trying to use a Shuttle Pro, it works with Mach apparently.
[18:00:25] <jepler> it looks like the configure.in autodetection could potentially be improved but .. shrug
[18:00:31] <seb_kuzminsky> all i have access to is the shuttlexpress
[18:00:44] <memleak> HAL_LIB: ERROR: clock period too long: 999848 Has anyone seen that before?
[18:00:58] <memleak> or know what it means so i can fix it?
[18:00:58] <andypugh> I don't even have that. He doesn't sound like the recompiling type, unfortunately.
[18:01:15] <seb_kuzminsky> have him send me the device he wants support for and i'll add it ;-)
[18:01:29] <memleak> jepler, yeah it's ugly isn't it?
[18:01:44] -!- mr_new has quit [Read error: Connection reset by peer]
[18:01:47] <memleak> i tried reworking it but with very little success.
[18:01:48] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:01:54] -!- ktchk has quit [Remote host closed the connection]
[18:01:59] <andypugh> seb_kuzminsky: He appears to be in Bekely, Michigan.
[18:02:07] <jepler> /* make sure period <= desired period (allow 1% roundoff error) */
[18:02:10] <jepler> if (curr_period > (period_nsec + (period_nsec / 100))) {
[18:02:13] <jepler> rtapi_mutex_give(&(hal_data->mutex));
[18:02:15] <jepler> rtapi_print_msg(RTAPI_MSG_ERR,
[18:02:17] <jepler> "HAL_LIB: ERROR: clock period too long: %ld\n", curr_period);
[18:02:21] <jepler> return -EINVAL;
[18:02:22] <jepler> memleak: what clock period is being requested?
[18:02:24] <jepler> }
[18:02:42] <jepler> umm this may be the behavior you get when you try to create a slow thread first and a fast thread second...
[18:02:53] <memleak> I'm trying to run the latency test in a PREEMPT_RT kernel
[18:02:58] <memleak> THREADS: ERROR: could not create thread 'fast'
[18:03:02] <jepler> threads must be created from fastest to slowest
[18:03:44] <memleak> Does a clock period have to do with latency? Will the test not even run if the latency is terrible?
[18:03:52] <jepler> this is not about latency
[18:05:01] -!- fomox has quit [Ping timeout: 245 seconds]
[18:05:13] <memleak> How would one go about... "shortening" the clock period?
[18:06:47] <memleak> I'm probably running on a terribly configured kernel right now but if you think latency isn't the issue..
[18:07:43] <jepler> what command are you running for your latency test?
[18:08:48] <memleak> sudo latency-test because i forgot to run sudo make setuid apparently in EMC: rtapi_app: cannot gain I/O privileges - forgot 'sudo make setuid'?
[18:09:23] <memleak> running latency-test (the one in EMC) with root permissions gets I/O privileges it seems. but a new problem emerges.
[18:09:32] <memleak> (the clock period problem)
[18:11:46] <jepler> with the latency-test not running, does 'halcmd show thread' show any threads?
[18:11:48] <memleak> hmm.. sudo make setuid && sudo make install doesn't fix the sudo make setuid problem..
[18:11:58] <memleak> no
[18:12:34] <memleak> maybe for PREEMPT_RT i need to remove the contents of /etc/security/limits.conf ?
[18:12:50] <jepler> I don't know the answer to that
[18:12:56] <memleak> I currently have the soft and hard memlocks at 20480
[18:14:46] <jepler> try running the latency test with just a servo thread: latency-test 1ms -
[18:15:21] -!- pib1964 has quit [Remote host closed the connection]
[18:15:45] <psha> removing limits.conf definitely would not help
[18:15:50] <psha> defaults are tiny
[18:16:09] <memleak> that works jepler
[18:16:42] <memleak> like i said, my kernel is awful: ERROR: Missed scheduling deadline for task 1 [1 times]
[18:16:42] <memleak> Now is 3322.867721381, deadline was 3322.867137315
[18:16:42] <memleak> Absolute number of pagefaults in realtime context: 7
[18:16:53] <jepler> OK, now see whether one of the following works: latency-test 1ms 25us OR latency-test 25us 1ms
[18:17:43] <memleak> latency-test 1ms 25us results in the same clock period problem
[18:18:02] <memleak> they both have the same clock period problem
[18:18:14] <jepler> that's weird
[18:18:27] <memleak> my latency went up to over 10 million in just a few seconds
[18:18:38] <memleak> you sure this isn't latency issue?
[18:18:39] <jepler> what branch/ref are you on?
[18:19:14] <memleak> rtos-integration-preview3-merged-into-master
[18:21:51] <memleak> is there any chance any of this is related to a kernel config? Because I was horsing around with a lot of the options trying to see what would even boot.
[18:22:42] <memleak> aside from the latency jitter issues, obviously.
[18:22:46] <jepler> memleak: cd tests/threads.0; halrun test.hal
[18:23:12] <jepler> does this print an error similar to the earlier error, or does it spew a bunch of numbers (maybe about 3500 of them)
[18:23:30] <memleak> the only file in "tests" is mathtest.c
[18:23:46] <jepler> not linuxcnc/src/tests, linuxcnc/tests
[18:23:53] <memleak> ah
[18:24:32] <memleak> clock period error again
[18:25:31] <memleak> note that whenever i get a clock period error, i always get the "could not create thread 'fast'" along with it
[18:25:50] <memleak> how can I fix this "sudo make setuid" problem as well?
[18:26:21] <seb_kuzminsky> we're getting tons of snow here, and my coworker suggested mounting a snowblower on the arm of a backhoe and cnc-ing it and carving giant snow sculptures :-)
[18:27:36] <memleak> i have to run everything as root over here in order for anything to do anything
[18:28:59] <jepler> memleak: it should not be that way, but I don't know whether it's your mistake or something not finished in the rtos branch (requirement to 'sudo halrun' or whatever)
[18:29:52] <jepler> memleak: try this: "halrun" (or sudo halrun as you say it is necessary on your system) then: loadrt threads name1=fast period1=1000
[18:29:57] <jepler> does that give the same error or a different one?
[18:30:16] <memleak> loadrt: command not found
[18:30:27] <memleak> ah, into halrun, one second
[18:30:29] <jepler> the first "halrun" should have given you a halcmd prompt
[18:30:52] <memleak> clock period + fast error
[18:31:32] <jepler> in that same halrun, 'show thread' shows no threads?
[18:31:44] <memleak> no threads
[18:32:10] <jepler> mhaberler: is it possible that rtapi_data->timer_period is not being cleared?
[18:32:25] <jepler> mhaberler: I expected that last test to result in this message: RTAPI: ERR: clock_set_period: %ld nsecs, out of range
[18:32:37] <memleak> what exactly are we trying to find out?
[18:32:53] <jepler> memleak: one last test: latency-test 500us -
[18:32:57] <jepler> I bet this one will fail in the same way
[18:33:14] <memleak> yep. failed
[18:33:27] <memleak> is there any chance a kernel recompile can fix the issue?
[18:33:37] <memleak> with a config that isn't completely borked?
[18:33:40] <jepler> no, I strongly suspect it's a linuxcnc bug in the rtos branch
[18:33:47] <mhaberler> reading back..
[18:33:50] <memleak> ok.
[18:33:50] <mhaberler> what os?
[18:34:00] <jepler> mhaberler: RT-PREEMPT I think
[18:34:06] <memleak> yep.
[18:35:17] <jepler> mhaberler: creating a 500us thread as the only thread fails because rtapi_clock_set_period(0) returns ~1ms even when no other thread has been created
[18:35:30] <mhaberler> hm
[18:35:54] <memleak> the only one that worked so far is sudo latency-test 1ms -
[18:36:08] <jepler> so now I'm wondering if the basic clock period set by an earlier run is somehow sticking in a later run
[18:36:28] <jepler> but I don't know anything about what would / would not cause rtapi_data->timer_period to be zero'd out
[18:36:32] <mhaberler> 'the only one' of what, runtests
[18:36:34] <jepler> .. in your branch
[18:37:04] <mhaberler> ok, will try to reproduce
[18:37:23] <memleak> mhaberler, jepler told me to run a bunch of different latency tests and the only one that actually opened up the new window was that one.
[18:37:29] <jepler> mhaberler: from a fresh boot, I'd try creating a 1ms thread then quitting realtime then in a new realtime try creating a 25us thread..
[18:37:41] <mhaberler> memleak: can you pastebin exact steps which lead to the error, plus kernel version
[18:37:54] -!- linuxcnc-build_ [linuxcnc-build_!~linuxcnc-@174-16-193-209.hlrn.qwest.net] has joined #linuxcnc-devel
[18:38:06] <memleak> which error are we talking about here?
[18:38:14] <mhaberler> all of them, in order
[18:38:25] <mhaberler> the thread one bugs me most
[18:38:39] <jepler> memleak: 'clock period too long'
[18:39:04] <jepler> though mhaberler probably also takes an interest in why 'sudo make setuid' doesn't suffice
[18:39:19] -!- seb_kuzminsky has quit [Ping timeout: 256 seconds]
[18:39:38] <mhaberler> unfortunately yes;)
[18:39:42] -!- linuxcnc-build has quit [Ping timeout: 256 seconds]
[18:40:56] -!- seb_kuzminsky [seb_kuzminsky!~seb@174-16-193-209.hlrn.qwest.net] has joined #linuxcnc-devel
[18:42:05] <memleak> http://dpaste.com/1059498/
[18:42:35] <mhaberler> please paste config.log
[18:43:24] <memleak> http://dpaste.com/1059499/
[18:43:29] <memleak> that one is cleaner
[18:43:32] <memleak> config.log ?
[18:43:42] <mhaberler> src/config.log
[18:44:06] <mhaberler> the result of running ./configure in src
[18:44:18] -!- skunkworks has quit [Quit: Leaving]
[18:44:22] <memleak> ok
[18:44:59] <memleak> http://www.fpaste.org/NdQ6/
[18:45:35] <mhaberler> sorry, what kernel is this?
[18:45:52] <memleak> 3.6.11-rt32
[18:46:08] <mhaberler> gentoo?
[18:46:12] <memleak> SMP PREEMPT RT
[18:46:17] <memleak> yes
[18:46:20] <mhaberler> I can read that, thanks
[18:46:36] <memleak> want a dmesg?
[18:46:57] <memleak> its pretty ugly :P
[18:47:04] <mhaberler> yes
[18:47:23] <memleak> 74K are you serious!?!
[18:47:30] <mhaberler> yes I am
[18:47:40] <memleak> no i mean the file size of the dmesg
[18:47:45] <memleak> I'm shocked it's this big
[18:48:25] <mhaberler> could you reproduce of doing this on a wheezy install, I lack the resources to track random distros
[18:48:59] <memleak> http://www.fpaste.org/THvv/
[18:49:00] <mhaberler> please also post the result of runtests+
[18:49:14] <memleak> don't bother tracking the distro
[18:50:55] <mhaberler> sorry, that boot shows all sorts of issues - vmalloc failures and whatnot
[18:51:12] <mhaberler> I will setup a wheezy rt-preempt system and try on this
[18:51:14] <memleak> so it is kernel related after all, yes?
[18:51:31] <mhaberler> I have no idea, but that looks rather odd - did you look?
[18:51:46] <memleak> yes i did.
[18:52:03] <memleak> jepler's attitude was simply to not worry about any of that stuff
[18:52:10] <mhaberler> as I said - I am happy to compare on a comparable setup, that would be either precise or wheezy with the wheezy rt-preempt kernel
[18:52:37] <memleak> I'm going to fix all those errors, give me a few minutes
[18:52:39] <mhaberler> have you run 'runtests' after building?
[18:52:58] <mhaberler> if not, please do so and post the output
[18:53:05] <memleak> runtests?
[18:53:15] <memleak> where is that?
[18:53:17] <mhaberler> regression tests
[18:53:28] <mhaberler> in scripts like the rest
[18:53:50] <mhaberler> note that this branch builds and runs the runtests scripts successfully, so please verify that first
[18:53:58] <memleak> how do i run it?
[18:54:17] <mhaberler> . scripts/rip-environment
[18:54:19] <mhaberler> runtests
[18:54:39] <memleak> This script is only useful on run-in-place systems.
[18:55:18] <mhaberler> you installed right over /usr ?
[18:55:22] <mhaberler> man..
[18:55:28] <mhaberler> please do this:
[18:55:28] <memleak> yes i did.
[18:55:39] -!- ekolojik has quit [Changing host]
[18:56:08] <mhaberler> ./configure # note: zero arguments
[18:56:19] <mhaberler> first make clean, then configure, make, make setuid, runtests, post result
[18:57:34] <memleak> i'll do that after i fix my kernel
[18:57:39] <mhaberler> whenever
[18:57:49] <memleak> take care mhaberler i'll be on later!
[18:57:52] -!- gasbakid has quit [Max SendQ exceeded]
[18:57:55] <memleak> thanks for the help!
[18:58:21] <jepler> mhaberler: so my hypothesis about HTR is: make sure the first time loading threads after a fresh boot, you create a 1ms thread as the first thread
[18:58:25] <mhaberler> however, I cannot spend time on your setup unless its either wheezy or precise and the wheezy kernel
[18:58:33] <jepler> mhaberler: then quit that hal session, and in a new one try to create a 25us or 100us or 500us thread
[18:58:46] <mhaberler> that tickles it?
[18:58:50] <jepler> I don't know
[18:58:58] <jepler> I don't have a rt-preempt system to test
[18:59:19] <memleak> mhaberler, why do you insist that this is gentoo related? do you have any evidence that supports that absolutely ridiculous theory?
[18:59:21] <mhaberler> I dimly remember something odd with the threads module; it unloads but it might not remove the HAL name entry for the thread
[19:00:06] <mhaberler> I just dont have the time to track this and that - we are building on these platforms, and for those I will assure it works
[19:00:23] -!- cncbasher has quit [Remote host closed the connection]
[19:01:32] <mhaberler> I'll have to setup wheezy/rtpreempt on a real box; since its timing related vbox isnt that much help
[19:07:57] -!- gasbakid has quit [Max SendQ exceeded]
[19:09:11] -!- |1li has quit [Ping timeout: 245 seconds]
[19:09:14] -!- jfire has quit [Read error: Connection reset by peer]
[19:09:49] -!- gimpswork has quit [Read error: Connection reset by peer]
[19:10:13] <memleak> so you can at least help with the timing issue even though i'm not on debian?
[19:12:24] <mhaberler> I will look at it after you have posted runtests results
[19:12:30] <memleak> ok thanks!
[19:12:36] -!- toastydeath has quit [Read error: Connection reset by peer]
[19:12:50] <memleak> memleak checking out.
[19:12:58] -!- memleak has quit [Quit: Leaving]
[19:13:21] -!- hashfail_ has quit [Ping timeout: 245 seconds]
[19:17:30] jd is now known as Guest18884
[19:20:29] -!- mrsun has quit [Quit: Leaving]
[19:26:10] -!- gasbakid has quit [Max SendQ exceeded]
[19:34:10] -!- psha has quit [Quit: Lost terminal]
[19:35:14] -!- pjm_ has quit [Read error: Connection reset by peer]
[19:50:04] -!- pjm_ has quit [Read error: Connection reset by peer]
[19:52:07] -!- mr_new has quit [Ping timeout: 245 seconds]
[20:04:59] -!- mhaberler has quit [Quit: mhaberler]
[20:11:38] -!- odogono has quit [Quit: odogono]
[20:11:38] -!- ler_hydra has quit [Remote host closed the connection]
[20:15:13] -!- gimpswork has quit [Ping timeout: 240 seconds]
[20:32:16] -!- krusty_ar_ has quit [Remote host closed the connection]
[20:34:12] -!- toastydeath has quit [Ping timeout: 245 seconds]
[20:49:28] -!- tmcw has quit [Remote host closed the connection]
[21:00:14] -!- L84Supper has quit [Ping timeout: 256 seconds]
[21:01:33] -!- FinboySlick has quit [Quit: Leaving.]
[21:03:35] jd is now known as Guest78335
[21:04:31] -!- Guest18884 has quit [Read error: Connection reset by peer]
[21:09:12] -!- markvand1nborre has quit [Ping timeout: 264 seconds]
[21:12:53] -!- DJ9DJ has quit [Quit: bye]
[21:16:56] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[21:19:41] -!- ekolojik has quit [Quit: Konversation terminated!]
[21:19:47] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[21:23:58] <mhaberler> memleak: I cannot reproduce your error
[21:24:37] <mhaberler> amd64/wheezy/3.2.0-4-rt-amd64 - 120/120 runtests ok, latency-test runs fine
[21:25:00] -!- shurshur has quit [Ping timeout: 245 seconds]
[21:25:12] -!- Wildhoney has quit [Ping timeout: 260 seconds]
[21:38:42] <jepler> mhaberler: thanks for trying it out
[21:44:15] <jepler> checking for a suitable libm... nm: 'tests/mathtest': No such file
[21:44:15] <jepler> libm OK to use.
[21:44:37] <jepler> hm is this nm diagnostic expected? configuring for rt-preempt using branch rtos-integration-preview3-merged-with-master from just now
[21:45:16] -!- motioncontrol has quit [Remote host closed the connection]
[21:45:55] -!- krusty_ar_ has quit [Remote host closed the connection]
[21:47:52] <jepler> fwiw I installed the wheezy rt kernel and tried my guess at HTR and that didn't reproduce it either
[21:49:53] <jepler> as expected, curr_period is 0 after curr_period = rtapi_clock_set_period(0);
[21:52:00] -!- Guest78335 has quit [Read error: Connection reset by peer]
[21:52:26] <jepler> I wonder what might make clock_getres(CLOCK_MONOTONIC, &res); return a value much bigger than the 1ns it returns here
[21:52:51] <jepler> .. as big as the ~1ms that memleak seems to get
[21:54:51] <mhaberler> to be honest, I never got that far down in configure,in ;)
[21:55:56] -!- L84Supper has quit [Quit: <puff of smoke>]
[21:59:24] <jepler> http://hans.fugal.net/blog/2011/11/27/clock_getres-and-clock_gettime/
[21:59:27] <jepler> same magic number, 999848
[22:01:45] <jepler> so yes it is kconfig badness :-/
[22:01:55] <jepler> memleak: dunno if you look for your name in scrollback but here ya go
[22:03:07] <mhaberler> good catch!
[22:04:11] <jepler> so maybe there's something about the error message that could be improved, but it looks like rtapi is correctly detecting that the underlying platform says it can't give the timing requested
[22:04:46] -!- Poincare has quit [Read error: Operation timed out]
[22:06:31] -!- Nick001-Shop has quit [Ping timeout: 252 seconds]
[22:06:32] Nick001-Shop_ is now known as Nick001-Shop
[22:08:20] -!- mhaberler has quit [Ping timeout: 245 seconds]
[22:12:28] -!- PetefromTn has quit [Read error: Connection reset by peer]
[22:13:20] -!- largecheesepuff has quit [Ping timeout: 256 seconds]
[22:14:43] -!- syyl_ has quit [Ping timeout: 245 seconds]
[22:17:02] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[22:17:24] -!- Poincare has quit [Remote host closed the connection]
[22:27:31] -!- erictheise_ has quit [Quit: erictheise_]
[22:32:04] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:41:32] -!- ravenlock has quit [Ping timeout: 252 seconds]
[22:49:11] -!- asdfasd has quit [Ping timeout: 245 seconds]
[22:55:02] -!- tmcw has quit [Remote host closed the connection]
[22:56:06] -!- PetefromTn has quit [Ping timeout: 258 seconds]
[22:56:25] -!- mhaberler has quit [Quit: mhaberler]
[23:11:28] -!- andypugh has quit [Quit: andypugh]
[23:20:56] -!- jd896_ has quit [Client Quit]
[23:36:18] -!- jd896 has quit [Remote host closed the connection]
[23:36:48] -!- jpk has quit [Ping timeout: 245 seconds]
[23:47:42] -!- erictheise_ has quit [Quit: erictheise_]
[23:51:06] -!- PCW has quit [Remote host closed the connection]
[23:55:30] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[23:59:30] -!- Nick001-Shop has quit [Remote host closed the connection]
[23:59:47] -!- carper64_lb_ [carper64_lb_!~quassel@2.120.125.69] has joined #linuxcnc-devel
[23:59:59] -!- carper64_lb has quit [Ping timeout: 245 seconds]
