Back
[00:10:46] -!-
micges has quit [Quit: Ex-Chat]
[00:15:20] -!-
jr has quit [Quit: Ex-Chat]
[00:17:33] -!-
garage_seb has quit [Remote host closed the connection]
[00:18:38] -!-
raynerd has quit [Ping timeout: 240 seconds]
[00:26:41] -!-
atom1 has quit [Quit: Leaving]
[00:37:27] <joe9> jepler: thanks.
[00:37:42] <joe9> yay, my first patch to linuxcnc..
[00:42:18] <cradek> awesome
[00:42:29] <cradek> thanks, joe9. thanks, jepler, for the review
[00:42:59] -!-
JT-Shop has quit [Ping timeout: 260 seconds]
[00:45:43] -!-
syyl has quit [Quit: Leaving]
[00:51:32] -!-
mikegg has quit [Ping timeout: 246 seconds]
[01:06:41] -!-
atom1 has quit [Client Quit]
[01:12:48] Tom_itx is now known as
Tom_L
[01:13:01] Tom_L is now known as
Tom_itx
[01:15:31] -!-
rob_h has quit [Ping timeout: 276 seconds]
[01:23:44] -!-
GoSebGo has quit [Ping timeout: 246 seconds]
[01:45:49] morfic- is now known as
morfic
[02:06:31] <seb_kuzminsky> what do pci_get_device() and pci_dev_put() do? why is there only one pci_dev_put()?
[02:09:51] Tom_itx is now known as
Tom_L
[02:10:04] Tom_L is now known as
Tom_itx
[02:14:19] -!-
pcw_ has quit [Ping timeout: 260 seconds]
[02:14:40] -!-
pcw has quit [Ping timeout: 276 seconds]
[02:16:06] -!-
skunkKandT has quit [Remote host closed the connection]
[02:16:39] <alex_joni> http://gnugeneration.com/books/linux/2.6.20/kernel-api/re590.html
[02:17:30] <jepler> basically, for every pointer returned by pci_get_device there has to be something that "sinks" the reference. It can be by passing it to a subsequent pci_get_device call until NULL is returned, or by passing it to pci_dev_put
[02:17:42] <jepler> it's a reference counting system that has something to do with enabling hotplugging
[03:00:20] -!-
ries has quit [Ping timeout: 246 seconds]
[03:00:21] ries_ is now known as
ries
[03:07:18] -!-
pcw has quit [Client Quit]
[03:07:33] pcw_ is now known as
pcw
[03:12:47] <seb_kuzminsky> hmm
[03:13:28] <seb_kuzminsky> so if you call pci_get_device and it finds a device, then it returns device (which is non-NULL)
[03:14:21] <seb_kuzminsky> you then have to either pass the dev in to pci_get_device() to trade it for the next one, or you have to call pci_dev_put() to just give it up
[03:16:15] <seb_kuzminsky> doesnt that mean the driver needs to call pci_dev_put() in rtapi_app_exit()? none of the hunks in joe9's commit do that
[03:16:19] <seb_kuzminsky> or am i missing something?
[03:17:38] <seb_kuzminsky> and the vti driver calls pci_dev_put() to decrement the refcount when it *does* decide to use it
[03:17:54] <seb_kuzminsky> something is very wrong here, though it may well be my understanding of the pci api
[03:21:46] -!-
GoSebGo [GoSebGo!~GoSebGo@107.24.30.227] has joined #linuxcnc-devel
[03:28:17] -!-
garage_seb [garage_seb!~seb@75-166-181-154.hlrn.qwest.net] has joined #linuxcnc-devel
[03:38:25] -!-
koax_ [koax_!~kelb@p508D47D8.dip.t-dialin.net] has joined #linuxcnc-devel
[03:42:09] -!-
koax has quit [Ping timeout: 265 seconds]
[03:50:59] -!-
demacus_ has quit [Ping timeout: 245 seconds]
[04:02:49] <CIA-51> 03seb 07v2.5_branch * re3a55bd1aae2 10/docs/src/gcode/gcode.txt: docs: clarify arc center specification
[04:07:16] -!-
phantoxe has quit []
[04:34:13] -!-
atom1 has quit [Quit: Leaving]
[04:48:08] -!-
tom1987 has quit [Read error: Connection reset by peer]
[04:48:50] -!-
tom1987 [tom1987!~tom@121.237.177.34] has joined #linuxcnc-devel
[04:52:42] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[04:55:49] -!-
garage_seb has quit [Quit: Leaving]
[05:14:11] -!-
Gabe_ has quit [Ping timeout: 245 seconds]
[05:28:12] -!-
ve7it has quit [Remote host closed the connection]
[05:31:31] <joe9> build of the latest git version throws up this warning: WARNING: "__fixunsdfdi" [/home/j/dev/kernel/src/emc2/emc2-dev/src/hostmot2.ko] undefined!
[05:41:44] -!-
mozmck has quit [Ping timeout: 244 seconds]
[05:41:55] <joe9> do you notice all these warnings too? /home/j/dev/kernel/src/linux-2.6.38.8/include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders"
[05:42:07] <joe9> there are a lot of them.
[05:45:43] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[05:55:10] -!-
factor has quit [Ping timeout: 246 seconds]
[05:55:31] -!-
dgarr has quit [Ping timeout: 246 seconds]
[05:55:59] -!-
pcw has quit [Ping timeout: 245 seconds]
[05:56:17] -!-
pcw_ has quit [Ping timeout: 245 seconds]
[06:18:34] <seb_kuzminsky> joe9: i don't see any of those messages when building rt on lucid or sim on precise
[06:18:47] <seb_kuzminsky> what environment are you building in? what branch?
[06:19:00] <joe9> the git latest branch.
[06:19:13] <joe9> environment is a crux distro.
[06:19:27] <joe9> kernel is 2.6.38.8, latest rtai - vulcano
[06:20:01] <seb_kuzminsky> linuxcnc master branch?
[06:20:14] <seb_kuzminsky> this must be some 2.6.38 or volcano problem
[06:21:08] <joe9> vulcano has some warnings. not sure if that is propogated to linuxcnc.
[06:21:48] <joe9> quick question, the "timer frequency" of the kernel configuration -> Processor Type and Features. I have 100Hz, 250Hz, and 1000Hz.
[06:22:03] <joe9> which is the most suited for linuxcnc.
[06:22:34] <joe9> I am getting a pretty high latency with 1000Hz. I also had it pretty bad with 250Hz (but not this bad).
[06:22:56] <joe9> 100, 250, 300, 1000 are the choices.
[06:23:12] <joe9> seb_kuzminsky: any thoughts, please?
[06:23:39] <seb_kuzminsky> i dont know.... i haven't configured rtai since 2007... i just use the rtai & kernel that mozmck built for us for lucid
[06:24:22] <seb_kuzminsky> but maybe take a look at the linuxcnc kernel config for a view of what was at one time a good way to do it?
[06:24:40] <joe9> would you be able to check what the CONFIG_HZ on that kernel is?
[06:24:45] <joe9> if you do not mind.
[06:25:13] <seb_kuzminsky> sure, just a sec
[06:25:18] <joe9> thanks a lot.
[06:25:39] <joe9> it will be CONFIG_HZ_<100,250,300,1000>
[06:25:54] <seb_kuzminsky> CONFIG_NO_HZ=y
[06:25:58] <seb_kuzminsky> and
[06:26:10] <seb_kuzminsky> CONFIG_HZ_250=y
[06:26:10] <seb_kuzminsky> and
[06:26:16] <seb_kuzminsky> CONFIG_HZ=250
[06:26:23] <joe9> ok, thanks.
[06:26:23] <seb_kuzminsky> but i think only the first one matters
[06:26:49] <joe9> cool, i have that set.
[06:27:29] <seb_kuzminsky> with NO_Hz, i think there is no timer tick, so the Hz variable is unused? i don't really know...
[06:27:47] <seb_kuzminsky> hey i have a question about the pci commit you just did
[06:28:26] <seb_kuzminsky> i was talking with jepler about it earlier, can you read back about 3 hours?
[06:28:36] <seb_kuzminsky> logger[mah]:
[06:28:37] <logger[mah]> seb_kuzminsky: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2012-03-25.html
[06:28:39] <joe9> seb_kuzminsky: would you mind pasting your config?
[06:28:43] <seb_kuzminsky> sure
[06:29:04] <joe9> seb_kuzminsky: yes, i read what you mentioned.
[06:29:13] <seb_kuzminsky> what am i missing here?
[06:29:30] <joe9> there was jepler's patch that did everything that you mentioned. but, that would not compile when I tried it.
[06:30:17] <seb_kuzminsky> here's the official linuxcnc kernel config for lucid:
http://highlab.com/~seb/emc2/config-2.6.32-122-rtai
[06:30:52] <seb_kuzminsky> as i understand the pci api, your patch leaks pci dev descriptors when you unload the modules
[06:31:07] <joe9> i read the kernel documentation about the pci_find_device and i kind of understood (which in all probability might be mistaken) that pci_get_device is a like-for-like swap for the pci_find_device.
[06:31:22] <joe9> seb_kuzminsky: that is possible.
[06:31:41] <joe9> but, I am not sure though.
[06:32:32] <joe9> from googling around, there was not a lot of info other than that "if there is a check and that is all that is doing, then put it".
[06:32:45] <joe9> does that make sense?
[06:32:54] <joe9> thanks for the paste.
[06:34:12] <seb_kuzminsky> here's a page that makes me think you're missing pci_dev_put() in a bunch of places:
http://gnugeneration.com/books/linux/2.6.20/kernel-api/re590.html
[06:34:18] <seb_kuzminsky> that's from alex_joni
[06:36:01] <seb_kuzminsky> well, i got to go to bed now, nice talking with you, and welcome to linuxcnc!
[06:36:06] <joe9> oh, ok.
[06:36:10] <joe9> thanks for your help.
[06:46:19] <CIA-51> 03seb 07master * r3d7df6cada5c 10/src/configure.in: configure: report failure to find libmodbus2
[07:14:58] <CIA-51> 03mhaberler 07master * r6a4a00a1258e 10/src/emc/rs274ngc/ (4 files): interp/introspection: make predefined parameters Python-extensible
[07:14:59] <CIA-51> 03mhaberler 07master * r53bfa132d5ce 10/tests/remap/predefined-named-params/ (7 files): tests: exercise extending predefined named params by Python functions
[07:15:00] <CIA-51> 03mhaberler 07master * r11355dc497c2 10/docs/src/ (gcode/overview.txt remap/structure.txt): interp/docs: document extending introspection by new predefined named params
[07:18:03] <mhaberler> hi seb_kuzminsky, still around?
[07:18:26] <mhaberler> the libmodbus2 test isnt used yet so failing it isnt fatal
[07:18:56] <mhaberler> I intended to link gs2_vfd against it instead of the old modbus.c/h source
[07:29:01] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[07:29:25] -!-
GoSebGo has quit [Quit: Bye]
[08:45:19] -!-
mhaberler has quit [Quit: mhaberler]
[09:11:43] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:22:30] <mhaberler> oh, its not fatal anyway. disregard.
[09:29:49] -!-
DJ9DJ has quit [Quit: brb]
[09:44:33] -!-
rob_h [rob_h!~rob_h@5ace7079.bb.sky.com] has joined #linuxcnc-devel
[09:52:20] -!-
raynerd has quit [Ping timeout: 252 seconds]
[10:14:12] -!-
mhaberler_ [mhaberler_!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[10:16:08] -!-
mhaberler has quit [Ping timeout: 240 seconds]
[10:16:08] mhaberler_ is now known as
mhaberler
[10:35:25] <CIA-51> 03tissf 07v2.5_branch * rc219563f6ab3 10/docs/src/gcode/gcode_fr.txt: French doc: update and cleaning
[10:39:28] -!-
tom1987 has quit [Read error: Connection timed out]
[10:40:06] -!-
tom1987 [tom1987!~tom@121.237.177.34] has joined #linuxcnc-devel
[10:46:39] -!-
mhaberler has quit [Quit: mhaberler]
[10:46:49] -!-
raynerd has quit [Ping timeout: 245 seconds]
[10:55:30] -!-
tom1987 has quit [Read error: Connection reset by peer]
[10:55:55] -!-
tom1987 [tom1987!~tom@121.237.177.34] has joined #linuxcnc-devel
[10:59:58] -!-
jthornton [jthornton!~chatzilla@64.85.214.231.reverse.socket.net] has joined #linuxcnc-devel
[12:21:57] -!-
jthornton has quit [Quit: ChatZilla 0.9.88.1 [Firefox 10.0.2/20120215223356]]
[12:30:22] -!-
JT-Shop [JT-Shop!~chatzilla@64.85.215.111.reverse.socket.net] has joined #linuxcnc-devel
[13:00:04] -!-
syyl has quit [Ping timeout: 246 seconds]
[13:46:43] <alex_joni> hey JT-Shop
[13:47:07] <JT-Shop> Hi alex_joni
[13:47:51] <alex_joni> did you approve some accounts?
[13:48:13] <JT-Shop> yea, this morning
[13:48:19] <JT-Shop> a couple
[13:48:24] <JT-Shop> mess you up?
[13:48:36] <alex_joni> nope
[13:48:50] <alex_joni> was looking for them, and they didn't turn up :)
[13:48:59] <alex_joni> figured it was you, but wanted to make sure
[13:49:47] <JT-Shop> I'm still on shaky dial up till next Friday...
[14:03:24] -!-
Valen has quit [Quit: Leaving.]
[14:05:01] <alex_joni> ok.. hope it gets better for you :)
[14:05:02] <alex_joni> bbl
[14:08:04] -!-
Loetmichel has quit [Ping timeout: 244 seconds]
[14:23:52] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:37:38] 64MAA4HX9 is now known as
P_C_W
[14:41:21] P_C_W is now known as
pedro
[14:56:08] -!-
nots has quit [Ping timeout: 240 seconds]
[15:15:03] -!-
nots has quit [Ping timeout: 260 seconds]
[15:19:51] -!-
factor has quit [Read error: Connection reset by peer]
[15:24:56] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[15:30:14] -!-
nots has quit [Ping timeout: 265 seconds]
[15:37:59] -!-
isssy has quit [Quit: Bye Bye]
[15:44:24] -!-
nots has quit [Ping timeout: 250 seconds]
[15:54:38] -!-
raynerd has quit [Ping timeout: 240 seconds]
[16:13:15] Cylly is now known as
Loetmichel
[16:21:35] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[16:47:49] -!-
syyl_ws has quit [Remote host closed the connection]
[16:58:07] -!-
atom1 has quit [Quit: Leaving]
[17:15:00] <mhaberler> what's the opinion on adding backported ubuntu packages to linuxcnc? background: I would like to remove the cause for a segfault which required the LD_PRELOAD workaround for OpenGL apps (
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_workarounds).
[17:15:00] <mhaberler> This requires a libgl1-mesa-dri backport for lucid and hardy
[17:15:30] <mhaberler> and there is no such thing except roll-your-own
[17:16:31] <seb_kuzminsky> i dont want to become a distribution maintainer, and i'm worried about diluting our collective attention... but i'm not going to tell you not to
[17:16:53] <seb_kuzminsky> is it possible in this case to submit a bug upstream?
[17:17:20] <mhaberler> the bug is actually fixed in natty:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
[17:17:44] <mhaberler> but natty is the oldest package one can pull from the ubuntu archives
[17:17:54] <mhaberler> with the fix, that is
[17:18:21] <seb_kuzminsky> canonical has decided not to fix it in lucid?
[17:18:29] <mhaberler> seems like it, yes
[17:18:44] <cradek> 1. Do not compile with --enabgle-glx-tls
[17:19:08] <cradek> have you tried just rebuilding the lucid version like the initial reporter suggests?
[17:19:20] <cradek> (sadly a lot of stuff doesn't get fixed in the LTSes)
[17:19:41] <mhaberler> I havent built anything yet. I used the LD_PRELOAD workaround so far.
[17:19:48] <seb_kuzminsky> cradek: yeah that's a bummer...
[17:20:10] <seb_kuzminsky> the world moves forward, and everyone has to keep moving or fall behind
[17:20:11] <mhaberler> but that is a wart, and does only work for programs which get started by linuxcnc
[17:21:25] <cradek> how much remapping does one have to do before seeing this problem? I did not see it on my m6-remapped trunk machine
[17:21:36] <cradek> I'm trying to understand the impact of the wart
[17:22:59] <mhaberler> the consequence is: *either* you have the Python plugin initialized, AND any openGL app is started with LD_PRELOAD, or it fails - you cant have Python plugin initialized and have the Interp instantiated in an OpenGL app which doesnt have the workaround
[17:23:27] <mhaberler> I worked around it in linuxcnc.sh and ini options
[17:24:15] <seb_kuzminsky> we currently have several backported packages in the deb archive at linuxcnc.org, but each one makes me uncomfortable
[17:24:28] <seb_kuzminsky> it just seems like a debugging/maintenance problem waiting to happen
[17:25:11] <mhaberler> well, there's a timelimit on it; as we move past natty the issue goes away
[17:25:25] <seb_kuzminsky> yes, that's the happy future in my mind
[17:25:28] <mhaberler> same for libmodbus version3
[17:25:37] <cradek> but if you've worked around it already...
[17:25:44] <seb_kuzminsky> but we have folks who are resisting moving off dapper drake...
[17:26:24] <mhaberler> I dont like the logistics drag on it either
[17:27:40] <cradek> just to be clear, does workaround #22 fix it?
[17:27:47] <seb_kuzminsky> what's the downside with your current workaround? if people run a remapped linuxcnc, and start other opengl apps, something crashes?
[17:27:56] <mhaberler> yes
[17:28:02] <mhaberler> I have worked around it for all configs which have the workaround. Currently these are only the ones in configs/sim/remap. If folks edit some other config, add PYTHON, bang
[17:28:43] <mhaberler> provided they dont have the DISPLAY_LD_PRELOAD line in the ini as in the link above
[17:30:07] <seb_kuzminsky> that's pretty bad :-(
[17:30:20] <mhaberler> cradek: I lost #22 - what you're referring to
[17:30:44] <cradek> http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_workarounds
[17:31:07] <mhaberler> oh. yes, that positively takes care of it.
[17:32:03] <mhaberler> this causes the workaround as described by the initial reporter in
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219 because linuxcnc.sh looks at these ini vars
[17:32:13] <cradek> then I'd *really* prefer not to have a custom mesa build
[17:32:24] <cradek> that could cause us dependency hell
[17:33:04] <seb_kuzminsky> remapping is not in 2.5, just in master, right?
[17:33:10] <mhaberler> just master
[17:33:13] <cradek> it's near enough to the closed source drivers and that infrastructure to make me wary
[17:33:23] <seb_kuzminsky> folks on master should expect a bit of breakage ;-)
[17:33:53] <seb_kuzminsky> we should put a warning about this in the release notes for master
[17:33:53] <cradek> can we just put it off and decide later when it comes near time to release master?
[17:34:02] <mhaberler> sure.
[17:34:21] <seb_kuzminsky> yes i agree too
[17:34:22] <mhaberler> one intermediate fix would be to change linuxcnc.sh to default to the workaround
[17:35:01] <cradek> that feels pretty easy and harmless too
[17:35:40] <mhaberler> that would lessen surprise for those editing their own configs to add Python-related stuff (which is useful beyond remapping; for instance I'm looking into doing RFL through breakpoints in interp which would be Python expressions (actually watchpoints))
[17:35:44] <seb_kuzminsky> <mhaberler> I worked around it in linuxcnc.sh and ini options
[17:35:51] <seb_kuzminsky> is the workaround already in linuxcnc.sh in master?
[17:36:37] <mhaberler> conditional - if you add DISPLAY_LD_PRELOAD and TASK_LD_PRELOAD to an ini file and run master, the right thing happens
[17:36:43] <seb_kuzminsky> oh
[17:36:57] <mhaberler> if you dont, do something pythonic in the interp, and start a GL gui, bang
[17:37:06] <mhaberler> I rather avoid the bang
[17:37:28] <mhaberler> so I'll go for defaulting the workaround for master to 'yes'
[17:37:30] <seb_kuzminsky> i see, you were suggesting making linuxcnc.sh apply the workaround whether or not the user added the LD_PRELOAD to their .ini
[17:37:37] <mhaberler> right
[17:37:50] <mhaberler> its a support issue waiting to happen
[17:37:55] <seb_kuzminsky> agreed
[17:38:27] <seb_kuzminsky> i guess if we're going to have a wart, i'd prefer it to be hidden inside a program that no users look at, rather than in the .ini that they all have to worry about
[17:38:36] <mhaberler> right
[17:38:47] <seb_kuzminsky> is there a downside to always ldpreloading libstdc++?
[17:39:47] <mhaberler> none I could discern so far. I'm a bit wary of the 'magic pathname' /usr/lib/libstdc++.so.6 though
[17:40:12] <mhaberler> but then folks with a custom-build libstdc++ will be rare around here
[17:41:33] <seb_kuzminsky> if you rebuild libstdc++ you're on your own!
[17:41:55] <mhaberler> yep, well you should be punished to start with;)
[17:41:58] <seb_kuzminsky> hey, comment #34 claims it's fixed in maverick:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
[17:42:19] <seb_kuzminsky> bbl, have to go fix my son's stuffed animal ;-)
[17:42:34] <mhaberler> cu!
[17:48:01] <mhaberler> ok, rebuilding libgl1-mesa-dri spits out 15 packages worth 14MB. A bit on the stuffy side.
[17:59:13] <mhaberler> I'll see whether I can retrieve the ibstdc++.so path through configure
[18:12:32] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 10.0.2/20120216080748]]
[18:28:17] <seb_kuzminsky> mhaberler: vfs11_vfd does not compile with the libmodbus in precise (3.0.1)
[18:28:53] <mhaberler> hm.. will try on precise.. any logs? buildbot?
[18:30:11] <seb_kuzminsky> i'll push something to the buildbot that might show the problem... hold on
[18:30:35] <mhaberler> link or compile?
[18:30:38] <seb_kuzminsky> compile
[18:30:53] <seb_kuzminsky> Compiling hal/user_comps/vfs11_vfd/vfs11_vfd.c
[18:30:53] <seb_kuzminsky> gcc -c -I. -Ilibnml/linklist -Ilibnml/cms -Ilibnml/rcs -Ilibnml/inifile -Ilibnml/os_intf -Ilibnml/nml -Ilibnml/buffer -Ilibnml/posemath -Irtapi -Ihal -Iemc/nml_intf -Iemc/kinematics -Iemc/motion -Iemc/ini -Iemc/rs274ngc -Iemc/pythonplugin -I/home/seb/emc2.git/src/include -I/usr/include/python2.7 -Os -g -Wall -DULAPI -Wdeclaration-after-statement -DDEBUG -I/usr/include/modbus hal/user_comps/vfs11_vfd/vfs11_vfd.c -o objects/hal
[18:30:53] <seb_kuzminsky> /user_comps/vfs11_vfd/vfs11_vfd.o
[18:30:53] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c: In function ‘read_ini’:
[18:30:55] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c:471:13: error: ‘MODBUS_RTU_RTS_UP’ undeclared (first use in this function)
[18:30:58] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c:471:13: note: each undeclared identifier is reported only once for each function it appears in
[18:31:01] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c:472:15: error: ‘MODBUS_RTU_RTS_DOWN’ undeclared (first use in this function)
[18:31:04] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c:473:15: error: ‘MODBUS_RTU_RTS_NONE’ undeclared (first use in this function)
[18:31:09] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c: In function ‘main’:
[18:31:11] <seb_kuzminsky> hal/user_comps/vfs11_vfd/vfs11_vfd.c:967:2: warning: implicit declaration of function ‘modbus_rtu_set_rts’ [-Wimplicit-function-declaration]
[18:31:14] <mhaberler> I see
[18:31:14] <seb_kuzminsky> make: *** [objects/hal/user_comps/vfs11_vfd/vfs11_vfd.o] Error 1
[18:31:16] <seb_kuzminsky> 2 seb@precise-amd64 /home/seb/emc2.git/src> dpkg --status libmodbus-dev | grep Version
[18:31:18] <seb_kuzminsky> Version: 3.0.1-2
[18:32:05] <seb_kuzminsky> ok i just pushed a branch named build-with-modbus, i dont know if pbuilder will pick it up
[18:32:13] <seb_kuzminsky> i know dpkg-checkbuilddeps will not :-(
[18:33:11] <seb_kuzminsky> bbl
[18:37:37] <mhaberler> looks like its picking up an old (v2) modbus.h file
[18:44:06] <mhaberler> modbus.h should include modbus-rtu.h which includes these syms
[18:52:16] <mhaberler> strange.. could you verify that /usr/include/modbus/modbus.h includes modbus-rtu.h and /usr/include/modbus/modbus-rtu.h defines MODBUS_RTU_RTS_UP ?
[19:03:41] -!-
asdfasd [asdfasd!~grgrgrgrg@87-194-58-242.bethere.co.uk] has joined #linuxcnc-devel
[19:04:12] <asdfasd> hi anyone. can I ask here for some more advanced settings in emc2?
[19:18:00] -!-
micges [micges!~x@user-46-113-225-201.play-internet.pl] has joined #linuxcnc-devel
[19:19:10] -!-
micges_ [micges_!~x@user-109-243-218-112.play-internet.pl] has joined #linuxcnc-devel
[19:22:08] -!-
micges has quit [Ping timeout: 240 seconds]
[19:28:22] -!-
Mjolinor has quit [Quit: Leaving]
[19:36:58] <mhaberler> give it a try
[19:37:42] micges_ is now known as
micges
[19:39:23] -!-
vladimirek has quit [Remote host closed the connection]
[19:51:34] -!-
mhaberler has quit [Quit: mhaberler]
[19:52:41] -!-
psha has quit [Ping timeout: 244 seconds]
[20:06:38] -!-
mozmck has quit [Ping timeout: 240 seconds]
[20:10:38] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[20:17:20] -!-
DJ9DJ has quit [Quit: bye]
[20:18:19] -!-
A2Sheds has quit [Quit: puff of smoke]
[20:20:32] -!-
maximilian_h has quit [Quit: Leaving.]
[20:24:13] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[20:28:59] <seb_kuzminsky> mhaberler: the libmodbus-dev in precise does not have those macros
[20:29:17] <mhaberler> ok, then its version 2 of modbus
[20:29:35] <seb_kuzminsky> 130 seb@precise-amd64 /home/seb/emc2.git/src> dpkg -S /usr/include/modbus/modbus.h
[20:29:36] <seb_kuzminsky> libmodbus-dev: /usr/include/modbus/modbus.h
[20:29:36] <seb_kuzminsky> 0 seb@precise-amd64 /home/seb/emc2.git/src> dpkg --status libmodbus-dev | grep Vers
[20:29:36] <seb_kuzminsky> Version: 3.0.1-2
[20:29:36] <seb_kuzminsky> 0 seb@precise-amd64 /home/seb/emc2.git/src> grep -r MODBUS_RTU_RTS /usr/include/modbus
[20:29:38] <seb_kuzminsky> 1 seb@precise-amd64 /home/seb/emc2.git/src>
[20:29:41] <seb_kuzminsky> it claims to be 3.0.1
[20:29:56] <seb_kuzminsky> bbl
[20:33:05] -!-
JT-Shop has quit [Ping timeout: 260 seconds]
[20:35:16] <mhaberler> that is the original modbus-rtu.h from which the package should have been built:
https://github.com/stephane/libmodbus/blob/master/src/modbus-rtu.h
[20:35:48] <mhaberler> that has the syms.. should be in /usr/include/modbus/modbus-rtu.h
[20:44:56] -!-
FinboySlick has quit [Quit: Leaving.]
[21:05:38] -!-
pcw has quit [Ping timeout: 240 seconds]
[21:06:19] -!-
pedro has quit [Ping timeout: 276 seconds]
[21:06:45] -!-
micges has quit [Quit: Ex-Chat]
[21:11:54] -!-
phantoxe has quit [Disconnected by services]
[21:11:56] phantone is now known as
phantoxe
[21:14:58] -!-
raynerd has quit [Ping timeout: 260 seconds]
[21:18:33] -!-
bedah has quit [Quit: Ex-Chat]
[21:20:27] -!-
pedro has quit [Client Quit]
[21:45:29] -!-
mhaberler has quit [Quit: mhaberler]
[21:49:11] -!-
syyl_ has quit [Quit: Leaving]
[22:29:55] -!-
adb [adb!~adb@178-211-231-163.dhcp.voenergies.net] has joined #linuxcnc-devel
[22:41:45] <cradek> yay taxes are done
[22:50:24] -!-
MrTrick has quit [Ping timeout: 252 seconds]
[23:13:11] <joe9> seb_kuzminsky: What version of rtai are you running?
[23:13:30] <joe9> your config mentioned using a kernel of 2.6.32-122
[23:13:40] <joe9> but, that version is not supported by rtai.
[23:13:54] <joe9> the highest rtai version is ./base/arch/x86/patches/hal-linux-2.6.32.11-x86-2.6-03.patch
[23:14:08] <joe9> for the stable 3.8.1 release.
[23:14:21] <cradek> I think it's actually 2.6.32-22
[23:14:30] <cradek> i.e. 2.6.32
[23:14:41] <joe9> do you just get the 2.6.32.11 and patch it up to .22?
[23:14:43] <cradek> notice - not .
[23:14:53] <joe9> oh, gotcha.
[23:15:02] <cradek> the number after the - is not a kernel.org type number
[23:15:29] <joe9> cradek: does it mean that he could be on any 2.6.32.x series, correct?
[23:15:50] <joe9> i have a 2.6.32.11 kernel, patched up and all that. it has a kernel panice
[23:15:56] <joe9> /panice/panic
[23:16:02] <joe9> panic; do_ext; oops_end; no_context; __bad_area_nosemaphore; ? sub_preempt_count; ? inotify_d_instantiate; ? __d_instantiate; security_d_instantiate; bad_area_no_semaphore; do_page_fault; ? dput; __ipipe_handle_exception; ? trace_create_file; error_code+0x75/0x84; ? do_one_initcall; ?event_trace_init; ? kernel_init; ? kernel_init; ? kernel_thread_helper
[23:16:36] <joe9> the same config worked fine on a 2.6.38.8 kernel. ofcourse, I did the make oldconfig for the 2.6.32.11
[23:16:54] <joe9> but, am wondering if there was a certain bug in the kernel for that release that could have caused it.
[23:17:18] <cradek> sadly it is very typical for some kernels/rtai combinations to work and some not
[23:17:23] <joe9> cradek: what rtai version are you on?
[23:17:26] <cradek> it is very very hard to get a trusted setup
[23:17:28] <joe9> stable 3.8.1?
[23:17:36] <cradek> I use the linuxcnc build
[23:18:02] <joe9> the livecd, you mean?
[23:18:04] <cradek> ii rtai-modules-2.6.32-122-rtai 3.8.1-linuxcnc1
[23:18:13] <joe9> oh, ok.
[23:18:27] <joe9> how do i find out what 2.6.32.x it is using?
[23:18:34] <joe9> or, does it not matter.
[23:18:41] <cradek> do you mean the .config file?
[23:19:06] <joe9> no, the kernel release is linux-2.6.32.11
[23:19:16] <joe9> based on the .patch file in 3.8.1-linuxcnc1
[23:19:26] <joe9> http://codepad.org/STq0n8Z4
[23:19:36] -!-
Tom_L has quit [Client Quit]
[23:19:40] <joe9> are the patches available in the rtai 3.8.1
[23:20:36] <joe9> the linux-2.6.32.11 panics for me. now, I am trying to figure out if I should go to the next kernel release with a patch there.
[23:20:40] <cradek> I don't know how to be sure which patch was used
[23:21:15] <joe9> or, if i should go up by patching the linux-2.6.32.11 with more patches, which will take it > .11.
[23:21:36] <joe9> cradek: what would you recommend doing? from experience.
[23:22:56] <cradek> heh
[23:23:26] <cradek> my experience is use the linuxcnc builds and be thankful someone found a stable combination :-/
[23:23:53] <cradek> I last screwed with it in 2005 and 2006, when I was the poor sap who made our cds.
[23:23:55] <joe9> what is your uname -a
[23:24:06] <cradek> Linux max2 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010 i686 GNU/Linux
[23:24:46] <cradek> http://timeguy.com/cradek-files/emc/Makefile
[23:24:53] <cradek> looks like it **is** 2.6.32.11
[23:25:03] <cradek> this is the Makefile from linux-headers-2.6.32-122
[23:25:31] <joe9> drm33.2 is what i need.
[23:25:35] <joe9> cool, thanks for that.
[23:25:38] <cradek> np
[23:26:53] <cradek> these might be very valuable:
http://timeguy.com/cradek-files/emc/joe9.tar.gz
[23:28:35] <joe9> thanks. that will be helpful.
[23:37:50] -!-
JT-Shop [JT-Shop!~chatzilla@64.85.215.123.reverse.socket.net] has joined #linuxcnc-devel
[23:49:10] <joe9> cradek: this is a huge ask.
http://codepad.org/PTpb4DIG i cannot get the kernel source for 2.6.32-122. wondering if you might be able to put it up as you did the joe9.tar.gz.
[23:49:14] <joe9> if you do not mind?
[23:49:38] <joe9> cradek: if it is a bother, then that's ok. I will keep trying the ubuntu website.
[23:50:57] <cradek> http://linuxcnc.org/emc2/dists/lucid/base/source/
[23:51:11] <cradek> corresponding source for all our packages is in our apt repo
[23:51:56] <joe9> ok, thanks.
[23:52:26] <joe9> cradek: that is a good one. thanks a lot.
[23:52:31] <cradek> sure
[23:52:44] <joe9> i am assuming that the source there is patched with the rtai patch? correct?
[23:52:52] <cradek> that I don't know
[23:52:57] <joe9> ok, will check that.
[23:53:20] <cradek> it builds to make the right binary package, that's all that's guaranteed
[23:53:41] <cradek> I've been out of the loop for packaging kernel/rtai for a while
[23:55:40] <joe9> ok, thanks. what is the hostmot firmware stuff there?
[23:55:47] <joe9> is it something that everyone needs?
[23:57:01] <cradek> no, that's firmware for the many mesa smart-boards
[23:57:12] <cradek> people without mesa hardware can ignore that
[23:58:18] <cradek> bbl