Back
[07:11:29] <jepler> skunkworks: yes, hm2-eth still breaks non-eth mesa cards so it's unsuitable to merge.
[07:11:48] <skunkworks> Thanks - good morning
[07:25:35] <KGB-linuxcnc> 05jepler/rtos-uspace-apis fe811a7 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe811a7
[07:26:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 27ba555 06linuxcnc New branch with 45 commits pushed, 10116 files changed, 034443(+), 044027(-) since master/cd4180d
[07:26:47] <jepler> oh of course I screwed it up
[07:29:07] <linuxcnc-build> build #394 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/394 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:29:17] <linuxcnc-build> build #395 of 1402.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-amd64/builds/395 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:34:35] <linuxcnc-build> build #50 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/50 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:35:31] <linuxcnc-build> build #2238 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2238 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:35:34] <linuxcnc-build> build #2236 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2236 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:36:55] <linuxcnc-build> build #1441 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1441 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:37:02] <linuxcnc-build> build #2237 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2237 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:37:05] <linuxcnc-build> build #2238 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2238 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:37:17] <linuxcnc-build> build #2239 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2239 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:38:19] <linuxcnc-build> build #2236 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2236 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:40:49] <KGB-linuxcnc> 05jepler/rtos-uspace-apis 27ba555 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=27ba555
[07:41:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis bfaf093 06linuxcnc New branch with 46 commits pushed, 10116 files changed, 034452(+), 044026(-) since master/cd4180d
[07:41:50] <jepler> this'll be the good one
[07:42:05] <jepler> linuxcnc-build: keep on truckin'!
[07:42:05] <linuxcnc-build> What you say!
[07:45:12] <linuxcnc-build> build #2243 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2243 blamelist: Jeff Epler <jepler@unpythonic.net>
[09:29:18] <jepler> (I guess our buildbot doesn't report when a failed build is followed by a successful one? 0000.checkin says 'build successful' in the waterfall)
[09:32:14] <KGB-linuxcnc> 03Jeff Epler 05master eaf06c1 06linuxcnc Merge branch 'jepler/rtos-uspace-apis' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eaf06c1
[09:32:22] <cradek> !!!
[09:32:37] <cradek> that's awesome
[09:32:57] <KGB-linuxcnc> 05jepler/rtos-uspace 29859e0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=29859e0
[09:32:57] <KGB-linuxcnc> 05jepler/rtos-uspace-apis bfaf093 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bfaf093
[09:36:45] <KGB-linuxcnc> 05jepler/static-ftbfs d4d4b07 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d4d4b07
[09:38:29] <KGB-linuxcnc> 05jepler-modlinking d3fc0ed 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d3fc0ed
[09:38:29] <KGB-linuxcnc> 05jepler/rtapi-more-headers 7a94b70 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7a94b70
[09:41:20] <KGB-linuxcnc> 05jepler/rtos-uspace-hm2-eth 17de976 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17de976
[09:47:51] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth 66a85c5 06linuxcnc 10(6 files in 2 dirs) Add support for mesanet ethernet UDP boards 7i80 and 7i76E * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=66a85c5
[09:47:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth 6f53b7f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_test.c hm2_test: Don't crash on test case 12 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6f53b7f
[09:47:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth 6d37e58 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add more data to debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6d37e58
[09:47:53] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth 2f20332 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add retry with timeout to enqueue_read() to make sure that all requested data will be readed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f20332
[09:47:58] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth 2a49978 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: read watchdog with same packet like rest of data from board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2a49978
[09:48:03] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth f86322d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: enable debug logging in enqueue_write function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f86322d
[09:48:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth 9bd0ef5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: fix 64-bit build error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9bd0ef5
[09:48:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth 13f2a5e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2-eth: take the size of the structure, not size of address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13f2a5e
[09:59:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-for-2.6 0fc7ad3 06linuxcnc New branch with 43 commits pushed, 10114 files changed, 034407(+), 044031(-) since jepler/rtos-uspace-for-2.6/9a9384a
[10:05:57] <KGB-linuxcnc> 03Michael Geszkiewicz 05hm2-eth-for-2.6 d94c619 06linuxcnc 10(6 files in 2 dirs) Add support for mesanet ethernet UDP boards 7i80 and 7i76E * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d94c619
[10:05:57] <KGB-linuxcnc> 03Jeff Epler 05hm2-eth-for-2.6 9bae8db 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_test.c hm2_test: Don't crash on test case 12 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9bae8db
[10:05:57] <KGB-linuxcnc> 03Michael Geszkiewicz 05hm2-eth-for-2.6 75c0267 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add more data to debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75c0267
[10:05:59] <KGB-linuxcnc> 03Michael Geszkiewicz 05hm2-eth-for-2.6 131b84c 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add retry with timeout to enqueue_read() to make sure that all requested data will be readed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=131b84c
[10:06:03] <KGB-linuxcnc> 03Michael Geszkiewicz 05hm2-eth-for-2.6 0430afe 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: read watchdog with same packet like rest of data from board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0430afe
[10:06:08] <KGB-linuxcnc> 03Michael Geszkiewicz 05hm2-eth-for-2.6 417f0a9 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: enable debug logging in enqueue_write function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=417f0a9
[10:06:13] <KGB-linuxcnc> 03Jeff Epler 05hm2-eth-for-2.6 4577b69 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: fix 64-bit build error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4577b69
[10:06:17] <KGB-linuxcnc> 03Jeff Epler 05hm2-eth-for-2.6 bb35e64 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2-eth: take the size of the structure, not size of address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb35e64
[10:06:36] <KGB-linuxcnc> 05hm2-eth-for-2.6 bb35e64 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb35e64
[10:06:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-for-2.6 d94c619 06linuxcnc 10(6 files in 2 dirs) Add support for mesanet ethernet UDP boards 7i80 and 7i76E * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d94c619
[10:06:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-for-2.6 9bae8db 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_test.c hm2_test: Don't crash on test case 12 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9bae8db
[10:06:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-for-2.6 75c0267 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add more data to debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75c0267
[10:06:59] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-for-2.6 131b84c 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add retry with timeout to enqueue_read() to make sure that all requested data will be readed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=131b84c
[10:07:04] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-for-2.6 0430afe 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: read watchdog with same packet like rest of data from board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0430afe
[10:07:09] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-for-2.6 417f0a9 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: enable debug logging in enqueue_write function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=417f0a9
[10:07:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-for-2.6 4577b69 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: fix 64-bit build error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4577b69
[10:07:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-for-2.6 bb35e64 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2-eth: take the size of the structure, not size of address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb35e64
[10:31:19] <dgarr> jepler: i'm having a problem with uspace hal_parport using the 'in' parameter:
http://www.panix.com/~dgarrett/stuff/uspace_hal_parport.txt
[10:43:23] <seb_kuzminsky> jepler: i'm excited for rt-preempt support in master, thank you!!!
[10:45:51] <cradek> halcmd: loadrt hal_parport cfg="0x378 in"
[10:45:52] <cradek> config string '0x378 in'
[10:45:52] <cradek> Linux parport #0 @0x378 0x778
[10:45:53] <cradek> <stdin>:14: /data/git_rt/linuxcnc-dev/bin/rtapi_app exited without becoming ready
[10:46:01] <cradek> dgarr: at this point does it put an error in dmesg?
[10:47:28] <dgarr> nope
[10:48:18] <cradek> huh!
[10:49:45] <jepler> argh, I failed to squash one of my commits in where it belonged. now it's part of history forever.
[10:50:14] <jepler> dgarr: hmmm, I did not test "in", that much is certain
[10:50:57] <jepler> cradek: if it's uspace, there's no dmesg
[10:51:08] <jepler> er, there's nothing that is going to be *in* dmesg
[10:51:15] <cradek> shows what I know about this brave new world
[10:53:42] <jepler> dgarr: I can duplicate that here
[10:59:13] <jepler> well I don't like this result one bit
[10:59:31] <jepler> I get dgarr's failure if the loadrt hal_parport is the first line but not if it's the second line after another loadrt line
[10:59:34] <jepler> that's ... weird
[11:01:26] <dgarr> same here -- very weird
[11:05:44] <seb_kuzminsky> strace should show you this initialization problem i'd think?
[11:06:34] <KGB-linuxcnc> 03Robert W. Ellenberg 05master dce4a75 06linuxcnc 10src/emc/tp/tp.c tp: fixed TP velocity target behavior * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dce4a75
[11:08:30] <seb_kuzminsky> yay, thanks Robert!
[11:09:12] <cradek> yay, a bugfix for breakage I hadn't even heard of yet
[11:09:17] <cradek> that's great
[11:15:05] <cradek> possibly appropriate for 2.6:
http://pastie.org/pastes/9409828/text
[11:16:50] <jepler> lgtm
[11:17:43] <cradek> the .py files I included are ones without #!
[11:18:15] <jepler> I saw that for the one I checked
[11:20:00] <seb_kuzminsky> jepler: you made commits b42f36d58 and 537a1e83, which adds libtk-img as a build-time dependency, but aren't those runtime dependencies? we already have them as that
[11:20:33] <cradek> hm, there are also some .tcl that are +x but do not contain #!
[11:21:06] <seb_kuzminsky> fucking permissions, how do they work?
[11:21:18] <jepler> seb_kuzminsky: we already do it for some other stuff. it helps users who use the output of ./configure to determine if they need to install additional software.
[11:29:48] <CaptHindsight> http://buildbot.linuxcnc.org/dists/wheezy/master-rt/binary-i386/ is all the new stuff in here except for the hm2_xxx?
[11:30:34] <cradek> eaf06c1 is the current master
[11:31:08] <cradek> er I'm wrong, rob's fix is after that
[11:31:42] <cradek> CaptHindsight: in those filenames after the ".g" is the git ref, so you can see exactly what you're getting
[11:40:54] <pcw_home> it great the uspace-apis is merged with master, now I can try our PCI cards and the new TP on a modern MB
[11:41:59] <jepler> dgarr, cradek: (actually, I think dmesg should have noted that rtapi_crashed with segmentation violation)
[11:42:36] <cradek> does that mean you found the problem?
[11:43:14] <cradek> I'd like to push these permission changes but I hate to tie up the buildbot with useless stuff
[11:43:23] <jepler> cradek: yes
[11:43:26] <cradek> yay
[11:44:40] <KGB-linuxcnc> 03Jeff Epler 05master fa82f4a 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: RT-harden before handling commandline * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa82f4a
[11:47:02] <cradek> that's some voodoo magic right there
[11:47:21] <cradek> glad I didn't try to figure that one out
[11:47:25] <jepler> hah
[11:48:04] <jepler> basically, getting I/O access for inb/outb happens by side-effect of constructing this "app" object
[11:48:26] <jepler> .. but that wasn't happening until certain RTAPI APIs were called, mostly those creating threads
[11:48:36] <jepler> so loadrt threads / loadrt hal_parport worked
[11:48:45] <jepler> loadrt hal_parport cfg="... io" didn't work
[11:48:58] <jepler> because it was doing an inb right in its rtapi_app_main
[11:49:19] <jepler> so, yeah, voodoo .. but caused by my possibly bad decision to create the app object only once it was required
[11:56:03] <dgarr> jepler: tested and works for me -- thanks
[11:58:15] <jepler> dgarr: welcome
[11:58:56] <jepler> dgarr: what parport hardware are you running? is the latency of -rt good enough for it?
[12:04:08] <dgarr> i have a pendant that runs off a pci parport card and hal_ppmc that runs off mobo parport, i am pretty sure it will be ok,
http://www.panix.com/~dgarrett/stuff/uspace-rt.png
[12:04:15] <dgarr> just need hal_ppmc now
[12:08:04] <dgarr> pendant is
http://www.panix.com/~dgarrett/stuff/lpendant.jpg
[12:09:08] <jepler> dgarr: I see.
[12:09:49] <jepler> dgarr: I didn't port hal_ppmc, because I have no hardware to test it on. I am not aware that it has any "killer problems".
[12:12:05] <jepler> halcmd: loadrt hal_ppmc
[12:12:05] <jepler> Note: Using POSIX realtime
[12:12:05] <jepler> Linux parport #0 @0xc010 0xc000
[12:12:05] <jepler> Linux parallel port @888 not found
[12:12:05] <jepler> PPMC: checking EPP bus 0 at port 0378
[12:12:07] <jepler> PPMC: slot 0: nothing detected at addr 0 reads ff
[12:12:10] <jepler> well this looks plausible
[12:12:38] <jepler> dgarr: try
http://emergent.unpythonic.net/files/sandbox/0001-hal_ppmc-port-to-uspace.patch and let me know
[12:18:00] <jepler> dgarr: or, heck, push it if it works for you
[12:21:27] <seb_kuzminsky> heh
[12:34:09] <micges-dev> jepler: hm2_eth for 2.6 is only for preview or you want to merge it?
[12:43:50] <seb_kuzminsky> micges-dev: it's not mergable yet
[12:43:57] <seb_kuzminsky> it still needs the non-eth hm2 boards fixed
[12:59:55] <micges-dev> working on this
[13:02:51] <skunkworks> micges-dev, awesome!
[13:10:12] <seb_kuzminsky> great
[13:11:43] <cradek> 2.6 won't have uspace at all, will it?
[13:17:28] <dgarr> jepler: with patch i can use halrun and loadrt hal_ppmc and hal_parport cfg="0x1108 in" ok, but my (complicated) ini setup is failing, i will work up a report when I understand it better
[13:18:02] <dgarr> i have run the machine with the patched hal_ppmc but haven't got the pendant running yet
[13:23:24] <alex_joni> cradek: nope
[13:43:46] <dgarr> jepler: some isolation of the problem i mentioned with ini config:
http://www.panix.com/~dgarrett/stuff/prob_info.txt
[13:44:03] <jepler> cradek: no, but I left a 2.6-based uspace branch on git.l.o
[13:44:27] <jepler> dgarr: looking
[13:46:14] <jepler> dgarr: OK, it's something to do with haltcl, but not sure what yet...
[13:46:15] <jepler> $ halrun -T
[13:46:19] <jepler> haltcl: loadrt hal_parport cfg="0 in"
[13:46:24] <jepler> Invalid paramter `in'
[13:46:25] <jepler> ...
[13:46:34] <jepler> while the same cfg= works with 'halrun' / halcmd
[13:47:52] <linuxcnc-build> build #2248 of 0000.checkin is complete: Failure [4failed fetch branch to local git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2248 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Geszkiewicz <micges@wp.pl>
[13:56:32] <jepler> dgarr:
http://pastebin.com/tbS0cuac
[14:06:13] <jepler> dgarr: Tcl quoting doesn't work like you want
[14:06:13] <jepler> haltcl: lindex {list loadrt hal_parport cfg="0 in"} 3
[14:06:13] <jepler> cfg="0
[14:06:39] <jepler> in Tcl, a quote internal to a word doesn't really quote, not in the same way it does in a shell
[14:07:21] <jepler> this works in both haltcl and halcmd: loadrt hal_parport "cfg=0 in"
[14:14:06] <jepler> .. insmod does some stuff as far as argument interpretation that rtapi_app doesn't.
[14:14:29] <jepler> if you're content to change your hal .tcl files, I'd much rather not try to make rtapi_app bug-compatible with insmod
[14:18:45] <dgarr> jepler: yea -- got it working hal_ppmc and hal_parport both on uspace wheezy preempt_rt, i had unknowingly changed the quotes when i got a new pc to replace the amd machine (that wont work with rtai 2.4.9) and new pci parport card
[14:18:54] <dgarr> thanks for all your help
[14:19:07] <jepler> dgarr: you're welcome. So your conclusion is that hal_ppmc is working?
[14:19:11] <dgarr> s/2.4.9/3.4.9/
[14:19:29] <dgarr> yes i am running real hardware (just simple tests so far)
[14:19:42] <jepler> OK, I'll get it pushed to master branch.
[14:20:28] <KGB-linuxcnc> 03Jeff Epler 05master cdb7bfa 06linuxcnc 10src/Makefile 10src/hal/drivers/hal_ppmc.c hal_ppmc: port to uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cdb7bfa
[14:20:57] <dgarr> excellent -- my plan is to use rt_preempt instead of rtai now, i will report if i see problems
[14:21:23] <cradek> yay for early adoption
[14:24:27] <jepler> oh, this is the board with the timer problem we failed to fix?
[14:24:34] <jepler> what a PITA
[14:24:59] <cradek> ?
[14:25:22] <jepler> cradek: dgarr's machine that doesn't work with our recent kernel/rtai combos
[14:25:33] <cradek> oh right
[14:27:49] <dgarr> my amd machine won't work with rtai3.4.9 so i got an ebay new hp sff machine to replace it and that is what i will run uspace on. the amd machine is still avail if there is some new rtai to test. the amd machine didn't have good latency with uspace either if i remember correctly
[14:28:41] <micges-dev> jepler: hm2_pci on hm2_eth uspace branch is working, I just got this at exit
[14:28:44] <micges-dev> jepler:
http://pastebin.com/pHFs5Zwf
[14:29:35] <jepler> micges-dev: I have not seen that. do you get the same problem in master branch without your changes?
[14:30:17] <micges-dev> I'll check
[14:31:55] <jepler> micges-dev: that *probably* represents a memory allocation error, such as passing the same pointer to free twice
[14:32:06] <jepler> it could also represent an out-of-bounds memory access
[14:32:49] <micges-dev> it's in hm2_watchdog_cleanup()
[14:32:53] <micges-dev> brb
[14:47:30] <micges-dev> ok, no problem in master
[15:41:59] <CaptHindsight> I never noticed that Windriver Linux branch, their open Yocto RT kernel uses preempt_rt
[15:44:18] <CaptHindsight> if that's all that their closed version uses then I can see why nobody uses it for Linuxcnc anymore
[16:07:59] <jepler> CaptHindsight: interesting data point there
[16:14:05] <jepler> cradek: at some point we had wondered which platforms needed "libgl1-mesa-dri workaround"
[16:14:30] <jepler> cradek: the answer turns out to be: lucid does, newer doesn't. in particular, ubuntu fixed it in natty, so it's fixed in precise; and it's fixed in debian wheezy
[16:15:10] <jepler> so we can't remove the test and workaround while we support lucid
[16:17:03] <jepler> I have gotten this twice today during a parallel build, not repeated:
[16:17:04] <jepler> cp emc/kinematics/tc.h ../include/tc.h
[16:17:04] <jepler> cp: cannot stat `emc/kinematics/tc.h': No such file or directory
[16:17:04] <jepler> make: *** [../include/tc.h] Error 1
[16:17:04] <jepler> make: *** Waiting for unfinished jobs....
[16:17:17] <jepler> it doesn't look like emc/kinematics/tc.h is a generated file, so I'm puzzled
[16:18:10] <cradek> that file doesn't exist in master
[16:18:14] <cradek> he moved it
[16:20:51] <jepler> ah
[16:21:08] <jepler> so here's what happens: the way we invoke gcc to generate dependency information, it provides a do-nothing rule for each header
[16:21:11] <jepler> e.g.,
[16:21:12] <jepler> /usr/include/string.h:
[16:21:29] <jepler> this is to allow the compile to run after a header is removed, without having to "make clean" or remove outdated dependency information
[16:21:52] <jepler> unfortunately, this means that path is also a candidate for the header-install rules
[16:22:08] <jepler> .. this happened on the first build after I switched from a 2.6-ish tree to a master-ish tree
[16:23:53] <cradek> it's nice to know that there are always fresh new ways that moving/renaming files can bite you in the ass
[16:32:48] <jepler> that's one way to look at it
[16:32:57] <jepler> at least I know enough make to figure out why I'm being bitten
[16:37:34] <ssi> what does ja5 add to ja?
[16:38:06] <jepler> I think it is mostly just a rebased version of ja
[16:38:10] <ssi> ah
[16:38:11] <cradek> ja5 is rebased on a more current master, modified to get along with the new trajectory planner
[16:38:35] <cradek> ... and other changes, rapid override being the first one I can think of
[16:38:55] <cradek> ja5 is probably a bit out of date again by now
[16:41:40] <jepler> now I'm itching to pull the trigger on some deletion of outdated code. Looks like 8000 lines can go.
http://pastebin.com/NgPSrXCk
[16:41:59] <jepler> but like I told the mailing list, not before August 1
[16:43:10] <micges-dev> jepler: I think you should announce this also on emc-users
[16:43:22] <cradek> in master I support doing this
[16:43:34] <jepler> cradek: yes, in master. it would be crazy to remove stuff from 2.6 at this stage.
[16:43:41] <cradek> I'm sad because I still have pluto hardware, but I can use 2.5 or 2.6 to run it for years to come.
[16:44:09] <cradek> it needs to go sooner or later...
[16:44:24] <jepler> I still have a pluto or two too, but the quality of the board, the firmware, and the linuxcnc driver are all so much worse than hostmot2, and you can buy hostmot2 hardware now and probably still in 5 years
[16:45:10] <jepler> pluto removal is -4911 lines; rtl removal is -2691 lines; everything else is small potatoes
[16:45:12] <cradek> sure but it's already working and it's even prettied up in a box.
[16:45:37] <jepler> cradek: if you feel differently about pluto, you should offer to maintain it
[16:45:58] <jepler> any of this is off the chopping block if there's a maintainer
[16:46:21] <cradek> I wonder if it currently works. I should try it.
[16:46:34] <cradek> I can probably handle maintaining it if it already works
[16:47:27] <Tom_itx> what alternative hardware is out there beside mesa?
[16:48:07] <Tom_itx> that currently has support...
[16:48:48] <jepler> Tom_itx: we know ppmc works and has users
[16:51:14] <jepler> there are drivers for : ax5214, evoreg, gm, motenc, stg, tiro, vti, opto_ac5, and pcl720 that I have no personal or one-step-indirect knowledge of
[16:51:38] <micges-dev> Tom_itx: General Mechatronics from hungary is up to date and maintained
[16:52:23] <jepler> and there's pci_8255 which in my experience is a flawed card. I owned one and tried to develop the driver, but regularly experienced lockups just by writing to its I/O registers
[16:53:27] <Tom_itx> being from the US, mesa seems to be the most popular... would that be fair to say?
[16:53:34] <micges-dev> Tom_itx: motenc is also working but got problems with newest motherboards (don't know details)
[16:54:30] <jepler> Tom_itx: I feel Mesa is the best card because it has the most source code available under Free Software licenses
[16:54:49] <jepler> (in addition to the linuxcnc driver being GPL, the FPGA source is dual license GPL/BSD)
[16:55:20] <Tom_itx> just curious... all i seem to hear about in the channel is mesa and parallel port interfaces
[16:55:26] <Tom_itx> not much else ever seems to come up
[16:55:52] <jepler> the list of PCI or PCI-express cards that LinuxCNC supports is small
[16:56:04] <Tom_itx> right
[16:57:11] <jepler> and I am not aware of any that hit the price point of mesa and ppmc
[16:57:48] <Tom_itx> who is ppmc?
[16:57:55] <Tom_itx> i've not heard of them
[16:58:27] <jepler> Jon Elson's line of FPGA cards. It's a parallel-connected, fpga-based system.
https://pico-systems.com/PPMC.html
[16:58:55] <jepler> his cards tend to integrate the FPGA and isolated I/O on one board, and he's got a neat rack system which allows you to run 8(?) cards off one parallel port
[16:59:03] <jepler> yeah, it says 8
[17:00:09] <jepler> and for stepper systems, he has a single-card solution that takes those standard opto modules
https://pico-systems.com/univstep.html
[17:00:17] <Tom_itx> ahh yean i think i heard talk of those at the wichita fest
[17:00:24] <jepler> jon was there, iirc
[17:00:31] <Tom_itx> yep
[17:00:41] <jepler> and stuart has some of his hardware
[17:00:58] <jepler> he's got a few more cards, like a resolver-to-quadrature board.
https://pico-systems.com/motion.html
[17:01:07] <jepler> solid stuff from all I've been able to tell
[17:01:22] <jepler> dgarr also runs his hardware, I was reminded today
[17:03:44] <jepler> bbl
[19:04:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 7874d7b 06linuxcnc 10VERSION 10debian/changelog Update changelog & VERSION for 2.6.0~pre5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7874d7b
[19:04:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags aaaeede 06linuxcnc 03v2.6.0-pre5 LinuxCNC v2.6.0-pre5 (tagged commit: 7874d7b) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aaaeede
[19:04:28] <seb_kuzminsky> aaaeede
[19:08:17] <jepler> seb_kuzminsky: ooh signed tags
[19:24:42] <cradek> aaiieeeee
[19:26:34] <cradek> 2.6 smells more and more ready...
[19:26:47] <jepler> yeah, especially since he wouldn't let me push uspace to it
[19:29:04] <jepler> seb_kuzminsky: do you want me to do something like this, so package building can skip checking for runtime-only dependencies?
http://emergent.unpythonic.net/files/sandbox/0001-configure-optionally-skip-checks-for-runtime-depende.patch
[19:29:10] <jepler> default remains to check for runtime dependencies
[19:42:09] <andypugh> Darn it! I thought I had a really neat way for a Python M101 command to return a value ( linuxcnc.command().mdi(“#<retval> = 3”) but MDI can’t be used when G-code is running.
[19:51:39] <andypugh> Is there any other way to this?
[19:52:11] <andypugh> (sees the time, going to bed, will read back tomorrow)
[19:53:35] <cradek> all I can think of is to set a hal pin and then read it back in the gcode
[19:58:03] <jepler> huh, in autoconf you're not supposed to use shell "if" or "case"; instead, use M4 macros AS_IF and AS_CASE. because reasons.
https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Common-Shell-Constructs.html
[21:31:49] <KGB-linuxcnc> 03Jeff Epler 05master b34c2ee 06linuxcnc 10src/rtapi/uspace_common.h uspace: use rtapi_get_time to implement rtapi_get_clocks if necessary * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b34c2ee
[21:31:49] <KGB-linuxcnc> 03Jeff Epler 05master 37bc194 06linuxcnc 10src/rtapi/rtapi_bitops.h rtapi_bitops: fall back to implementation based on gcc intrinsics * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37bc194
[21:31:49] <KGB-linuxcnc> 03Jeff Epler 05master 7e58eae 06linuxcnc 10src/rtapi/vsnprintf.h rtapi_vsnprintf: Fix float formatting for !IS_IEEE754 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e58eae
[21:31:51] <KGB-linuxcnc> 03Jeff Epler 05master fa59679 06linuxcnc 10src/rtapi/vsnprintf.h rtapi_vsnprintf: arm IS_IEEE754 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa59679
[21:37:31] <jepler> so that ^^^ basicall ports to arm with rt-preempt, except for the concerns about the lack of atomic storage to values of type 'double'
[22:19:47] <KGB-linuxcnc> 03Jeff Epler 05master c3588ae 06linuxcnc 10src/hal/hal.h hal: explain why the enums all have distinct values * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3588ae
[22:19:48] <KGB-linuxcnc> 03Jeff Epler 05master 9c3578b 06linuxcnc 10src/hal/hal.h hal: use rtapi_bool.h for the type underlying hal_bit_t * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c3578b
[22:19:48] <KGB-linuxcnc> 03Jeff Epler 05master d862c1b 06linuxcnc 10src/hal/hal.h hal: use rtapi_stdint for the types underlying hal types * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d862c1b
