#linuxcnc-devel | Logs for 2014-06-30

Back
[00:01:25] <cradek> seb_kuzminsky: I think I have everything worked out: the lapic thing, and correct sources.list even if network is not available at install time (so we can still give the advice: go plug in a wire somewhere, and you'll get the updates)
[00:02:04] <cradek> so I think as soon as you get me a wheezy 2.6.something deb in l.o I'll be done
[00:02:27] <cradek> well it would be nice to figure out dewey's problem... I have not seen any problem on the hardware I've tested but obviously there's some regression somewhere.
[00:18:22] <seb_kuzminsky> cradek: did you run rtai on all those machines?
[00:18:28] <seb_kuzminsky> were any of them single-processor?
[00:18:31] <cradek> yes
[00:18:39] <seb_kuzminsky> ah, ok
[00:18:41] <cradek> certainly the P3-700 was single processor
[00:18:42] <seb_kuzminsky> well that's good
[00:19:00] <cradek> I bet the dell laptops were both single processor too
[00:19:18] <cradek> I think they are pentium M, and P4 something
[00:20:28] <cradek> I should try it on my dual P3-1000 which was historically kind of a pain
[00:24:53] <seb_kuzminsky> oh, the 2.6.0~pre4 debs built for wheezy-rtai-i386, but they didnt show up in release/ because i forgot to install the 2.6 tag-signing key on that buildslave, so it thought the release was bogus
[00:25:05] <cradek> oop
[00:25:06] <seb_kuzminsky> fetching deb from the normal non-release dists now...
[00:27:14] <seb_kuzminsky> keys installed...
[00:32:50] <seb_kuzminsky> rsyncing the updated deb archive to wlo now
[00:34:39] <seb_kuzminsky> ok, it's there!
[00:35:38] <cradek> yay!
[00:37:59] <seb_kuzminsky> oh man, jeplers work lately makes me all kinds of giddy
[00:39:04] <cradek> any last requests for packages on the live cd?
[00:39:39] <seb_kuzminsky> erm
[00:39:49] <seb_kuzminsky> none of the ones i want belong on the cd
[00:40:06] <seb_kuzminsky> tig, screen, vim
[00:40:27] <cradek> emacs and magit!
[00:40:32] <cradek> nah, you're right
[00:40:40] <seb_kuzminsky> hm, the upgrade from 3.4.55-rtai to 3.4-9-rtai-686-pae is not painless
[00:40:47] <seb_kuzminsky> the rtai-modules packages clash :-/
[00:41:32] <seb_kuzminsky> you can manually remove the old rtai-modules, then manually install the new one
[00:43:26] <cradek> Get:2 http://linuxcnc.org/ wheezy/2.6 linuxcnc i386 1:2.6.0~pre4 [12.8 MB]
[00:43:29] <cradek> whee
[00:44:07] <seb_kuzminsky> wow, it even worked? i'm flabbergasted
[00:44:15] <seb_kuzminsky> well, it *fetched* at least
[00:47:11] <cradek> it worked very easily, since I already had the key
[00:47:14] <cradek> for 'base'
[00:47:35] <cradek> I think this one will be good enough to share widely
[00:49:22] <seb_kuzminsky> sweet
[00:52:05] <linuxcnc-build> build #2201 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/2201 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy, Michael Geszkiewicz <micges@wp.pl>
[00:57:58] <seb_kuzminsky> well, i have a computer here that works fine with 3.4.55-rtai, but that i can reliably crash with 3.4-9-rtai-686-pae by plugging in a little wifi usb dongle
[01:03:26] <cradek> well that's irritating
[01:06:05] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/rtai-oops.jpg
[01:06:20] <linuxcnc-build> build #13 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/13 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy, Michael Geszkiewicz <micges@wp.pl>
[01:06:32] <seb_kuzminsky> that's a 2 vCPU machine
[01:09:40] <linuxcnc-build> build #1405 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/1405 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy, Michael Geszkiewicz <micges@wp.pl>
[01:11:28] <seb_kuzminsky> otoh, 3.4-9-rtai-686-pae just drove my bridgeport around (precise userspace)
[01:26:10] <linuxcnc-build> build #2204 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/2204 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy, Michael Geszkiewicz <micges@wp.pl>
[01:38:45] <seb_kuzminsky> cradek: my other computer here boots to the Live environment fine, but fails both Install and Graphical Install
[01:38:59] <seb_kuzminsky> i get a garbled unreadable screen
[01:39:18] <seb_kuzminsky> if i remove the vga=788 from the grub command line it works fine in Install mode (haven't tried Graphical Install)
[01:42:23] <seb_kuzminsky> it's been stuck at "Starting the Partitioner" for a good long while now (minutes and minutes)
[01:49:59] <linuxcnc-build> build #2205 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2205 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy, Michael Geszkiewicz <micges@wp.pl>
[02:10:44] <seb_kuzminsky> cradek: the hostmot2 firmwares are not on the livecd i have
[02:11:11] <seb_kuzminsky> (the one from june 27 with md5sum 552e0dade48ab33e61a79f51f268a7f3)
[02:12:03] <seb_kuzminsky> also, it's got a buildbot.list apt source, was that intentional?
[02:14:02] <seb_kuzminsky> the user should probably be added to the dialout group (so modbus works)
[02:18:32] <seb_kuzminsky> maybe lp too? i dont know if we use /dev/lp...
[02:19:19] <seb_kuzminsky> anyway, after adding the right hostmot2-firmware and group memberships, i could drive the bridgeport around using a wheezy-rtai-i386 machine installed from cradek's livecd from a couple of days ago
[02:19:26] <seb_kuzminsky> so: woohoooo!
[02:19:29] <seb_kuzminsky> and good night!
[07:04:01] <jepler> weird, I remain puzzled by dgarr's computer that doesn't work
[07:04:29] <jepler> kernel should leave the "dummy" flag on the api turned off if it prints "jiffies result ok", as it did in dgarr's log
[07:04:32] <jepler> /* Check, if the jiffies result is consistent */
[07:04:35] <jepler> if (deltaj >= LAPIC_CAL_LOOPS-2 && deltaj <= LAPIC_CAL_LOOPS+2)
[07:04:38] <jepler> apic_printk(APIC_VERBOSE, "... jiffies result ok\n");
[07:04:41] <jepler> else
[07:04:43] <jepler> levt->features |= CLOCK_EVT_FEAT_DUMMY;
[07:05:35] <jepler> oh, hm, in this version of the patch we have:
[07:05:35] <jepler> +#ifdef CONFIG_IPIPE
[07:05:35] <jepler> + if (!(lapic_clockevent.features & CLOCK_EVT_FEAT_DUMMY)
[07:05:35] <jepler> + && !cpu_has_amd_erratum(amd_erratum_400))
[07:05:35] <jepler> + levt->ipipe_timer = &__get_cpu_var(lapic_itimer);
[07:05:47] <jepler> I wonder what amd erratum 400 is
[07:06:20] <jepler> oh it's that C1E thing
[07:08:13] <jepler> except dewey has no bios option
[07:10:20] <jepler> it's tempting to delete the check from rtai, since dgarr's machine worked in the past
[07:20:46] <jepler> something like this (not even compile-testd): http://emergent.unpythonic.net/files/sandbox/c1e-nonfatal.patch
[07:23:31] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 052bf26 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=052bf26
[07:23:32] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 58958a9 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=58958a9
[07:23:32] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth fa692d3 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=fa692d3
[07:23:35] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 0016028 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=0016028
[07:23:40] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 0867ecc 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=0867ecc
[07:23:45] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth 913bd32 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=913bd32
[07:38:41] <linuxcnc-build> build #14 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/14 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Geszkiewicz <micges@wp.pl>
[07:51:38] <linuxcnc-build> build #1406 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1406 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Geszkiewicz <micges@wp.pl>
[07:55:52] <linuxcnc-build> build #2205 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2205 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Geszkiewicz <micges@wp.pl>
[07:58:29] <linuxcnc-build> build #2206 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2206 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Geszkiewicz <micges@wp.pl>
[08:04:51] <jepler> micges: at least as rebased against my uspace tree, the changes for hm2_eth make the realtime tests for hostmot2 (hm2_test) fail... :(
[08:05:27] <jepler> hi skunkworks
[08:06:32] <skunkworks> Good morning
[08:10:08] <jepler> skunkworks: what do you use for power on your 7i80? I see it says 5V/5A in the manual, though 4A of that is for the I/O connectors if I understand right
[08:19:50] <skunkworks> jepler, I am using a linksys 5v 2a for the bare 7i80
[08:20:29] <skunkworks> wall wart
[08:20:53] <skunkworks> (I have the HD version - 3 50 pin connectors)
[08:21:15] <skunkworks> nothing plugged into it
[08:27:01] <jepler> yeah
[08:27:26] <jepler> I probably shouldn't buy one, I have no use for it
[09:39:20] <dgarr> rtai2.6 reports a amd bios timer bug and works around it, rtai3.4 does not? http://www.panix.com/~dgarrett/stuff/compare_rtai_logs.txt
[09:39:58] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth 9fd527a 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=9fd527a
[09:48:42] <seb_kuzminsky> dgarr: by "rtai2.6", do you mean the 3.4.55-rtai-2 kernel? and by "rtai3.4", do you mean the 3.4-9-rtai-686-pae kernel?
[09:48:59] <seb_kuzminsky> if so, that might be because they use different rtai kernel patch versions...
[09:50:22] <dgarr> i mean rtai2.6 == 2.6.32-122-rtai and rtai3.4 == 3.4-9-rtai-686-pae
[09:52:01] <dgarr> eg rtai2.6 lucid running on same motherboard for years, rtai3.4 == latest available (i think)
[09:54:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis dcb4d84 06linuxcnc 10src/Makefile rtapi-uspace: Ask gcc for the semantics we want * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcb4d84
[09:54:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis f4d9ef5 06linuxcnc 10src/Makefile 03src/rtapi/rtapi_io.h rtapi: provide rtapi_io.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4d9ef5
[09:54:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis bc3686e 06linuxcnc 10src/rtapi/rtapi.h rtapi: provide (non-functional) request/release region for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc3686e
[09:54:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 962d342 06linuxcnc 10src/rtapi/rtapi.h rtapi: import EXPORT_SYMBOL_GPL for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=962d342
[09:54:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis fc8a424 06linuxcnc 10src/hal/drivers/serport.comp serport: use <rtapi_io.h> * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc8a424
[09:55:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 4a4091b 06linuxcnc 10src/hal/components/Submakefile serport: build for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a4091b
[09:55:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 000a60c 06linuxcnc 10(9 files in 2 dirs) rtapi: provide additional portability headers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=000a60c
[09:55:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis f870499 06linuxcnc 10src/rtapi/uspace_common.h rtapi-uspace: implement rtapi_delay * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f870499
[09:55:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 7390d0c 06linuxcnc 10(27 files in 2 dirs) hostmot2: build hostmot2 and hm2_test for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7390d0c
[09:55:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 8652528 06linuxcnc 03tests/hm2-idrom/.gitignore 10tests/hm2-idrom/check-dmesg 04tests/hm2-idrom/skip 10tests/hm2-idrom/test.sh hm2-idrom: Let test succeed in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8652528
[09:55:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 49868d8 06linuxcnc 10(8 files) rtapi: document new headers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49868d8
[09:55:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 6df86dd 06linuxcnc 10debian/configure 10src/Makefile.inc.in 10src/configure.in build: we'll require libudev from now on * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6df86dd
[09:55:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis ed77f61 06linuxcnc 10src/Makefile 10src/rtapi/Submakefile 03src/rtapi/rtapi_pci.cc 03src/rtapi/rtapi_pci.h uspace: implementation of PCI APIs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ed77f61
[09:55:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 3eaa0c7 06linuxcnc 10src/Makefile 10src/hal/drivers/mesa-hostmot2/hm2_pci.c 10src/hal/drivers/mesa-hostmot2/hm2_pci.h hm2_pci: rtapi-prefix APIs and enable for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3eaa0c7
[09:55:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 7161b97 06linuxcnc 03docs/man/man3/rtapi_pci.3rtapi rtapi: document new header * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7161b97
[09:55:44] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 90dc1b7 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=90dc1b7
[09:55:48] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth 80e3418 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=80e3418
[09:55:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 4cc929c 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=4cc929c
[09:55:57] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 470a6a7 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=470a6a7
[09:56:01] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 5cd840e 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=5cd840e
[09:56:06] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 6824352 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=6824352
[09:56:11] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth 2b89b5e 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=2b89b5e
[10:00:49] <jepler> dgarr: all I can see from here is that the 2.6.32-122-rtai code about this AMD erratum is quite different than in 3.4-9-rtapi
[10:01:20] <jepler> dgarr: I don't think any kernel commandline flag is going to fix it
[10:01:42] <dgarr> i imagine you are correct
[10:46:47] <seb_kuzminsky> dgarr: do you know if the earlier 3.4 rtai kernel i made works on that machine? ie, 3.4.55-rtai-2
[10:47:03] <seb_kuzminsky> i have a computer here that works fine with 3.4.55-rtai-2, but panics with 3.4-9-rtai-686-pae
[10:47:50] <seb_kuzminsky> those two rtai packages differ in the version of the linux kernel and rtai patch they use
[10:48:11] <dgarr> i tried the 3.4.55-rtai-2 kernel on that machine and the mouse wouldn't work (sigh)
[10:48:30] <seb_kuzminsky> i'm second-guessing now my decision to try to update the rtai/kernel version at the same time i updated the packaging stuff....
[10:48:43] <seb_kuzminsky> hmm, no mouse, maybe i forgot to add a driver for it? what kind of mouse is it?
[10:49:29] <seb_kuzminsky> i've used a couple of usb mice with that kernel without problem, is yours ps/2 maybe?
[10:50:27] <dgarr> ps/2 i think, working Xorg.0.log report is Adding input device ImPS/2 Logitech Wheel Mouse (/dev/input/event1)
[10:53:18] <seb_kuzminsky> right
[10:53:54] <seb_kuzminsky> i'm looking up my old kernel config now...
[10:57:03] <seb_kuzminsky> no, the ps2 mouse driver is enabled
[10:58:39] <seb_kuzminsky> strange
[10:58:45] <seb_kuzminsky> then i dont know why the mouse didnt work for you
[10:59:25] <jepler> seb_kuzminsky: 2.6 or master? http://emergent.unpythonic.net/files/sandbox/arm-patches.mbox.txt It makes linuxcnc build and pass tests on my arm chromebook running debian 7 in crouton, and only touch code paths not touched by our "real" builds
[11:00:21] <seb_kuzminsky> looking
[11:00:56] <seb_kuzminsky> wow, 2bcbdd5 is surprising to me
[11:01:00] <seb_kuzminsky> thanks for getting the actual numbers
[11:02:16] <jepler> for tsc on arm, none of the options seem great. but the perf interface, used by machinekit, seems to be the worst
[11:02:46] <seb_kuzminsky> haha, rtapi_bitops has support for powerpc
[11:03:06] <seb_kuzminsky> 1995 called, they want their alternative architectures back
[11:03:17] <jepler> yeah, I forget who authored that, but cradek actually developed linuxcnc on an old ppc macbook running linux for awhile
[11:03:28] <jepler> candy colored
[11:05:17] <seb_kuzminsky> is this him? http://www.penny-arcade.com/comic/1999/04/28
[11:06:10] <jepler> nah, cradek's not much of a player of games.
[11:06:24] <seb_kuzminsky> but he has cats...
[11:06:55] <seb_kuzminsky> your patchset looks safe, except i dont understand c5b6eaba, but it's not used anyway because 4efcbfa0, right?
[11:07:25] <seb_kuzminsky> i think adding arm support isn't helpful unless we also add uspace, and that should go in master instead of 2.6, so i think this patchset belongs in master too
[11:07:39] <jepler> OK, I think you're probably right but I still wanted to ask
[11:07:48] <seb_kuzminsky> yep, thanks
[11:07:55] <seb_kuzminsky> bbl
[11:07:57] <jepler> thanks for taking the time to look
[11:08:00] <jepler> me too
[11:14:16] <kwallace2> I'm having a issue with Glade deleting a sourceview feature whenever I save a file. Has anyone else seen this?
[11:20:00] <seb_kuzminsky> kwallace2: i never use glade, so i've never seen that
[11:23:15] <kwallace2> seb_kuzminsky, thank you. It looks like it maybe checks for deprecated bits and chucks 'em. The 10.04 Glade is way old.
[11:35:28] <seb_kuzminsky> jepler: looks like you pushed a branch named "origin/jepler/rtos-uspace-hm2-eth", i think the 'origin/' doesnt belong in the branch name
[11:36:19] <skunkworks> logger[psha],
[11:36:19] <logger[psha]> skunkworks: Log stored at http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-30.html
[11:41:24] <jepler> seb_kuzminsky: if so, oops
[11:43:01] <KGB-linuxcnc> 05jepler/rtos-uspace-hm2-eth 2b89b5e 06linuxcnc branch created * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b89b5e
[11:43:28] <KGB-linuxcnc> 05origin/jepler/rtos-uspace-hm2-eth 2b89b5e 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b89b5e
[11:49:35] <seb_kuzminsky> i like how you keep both the rtos-uspace and rtos-uspace-hm2-eth branch pointers up to date through rebases - makes it easy to follow
[12:07:46] <jepler> seb_kuzminsky: aside from te chatter it creates on kgb // -commit, it's great.
[12:08:19] <jepler> seb_kuzminsky: wondering how long I should wait before merging any of this to master. thoughts?
[12:09:01] <jepler> cradek: for that matter I'd like your thoughts
[12:10:51] <jepler> rtos-uspace and rtos-uspace-apis, that is.
[12:11:13] <jepler> it'd be micges's show to decide on the rebased hm2-eth
[12:11:34] <jepler> and I think that branchh may break hm2-pci, not sure.
[12:12:34] <jepler> .. should I do epp apis before I merge? should I convert drivers I can't test?
[12:15:00] <CaptHindsight> what is next after rtos-uspace and rtos-uspace-apis and micges's rebased hm2-eth?
[12:15:41] <CaptHindsight> Is there anything else from machinekit that there is an interest in merging into master?
[12:16:21] <linuxcnc-build> build #2209 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/2209 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>, Jeff Epler <jepler@unpythonic.net>
[12:20:53] <seb_kuzminsky> jepler: i have the beginnings of a reusable epp driver in the branch called hm2-epp
[12:21:28] <seb_kuzminsky> i think i'm going to be up to my neck trying to un-hork our rtai packages for a little while yet, or i'd offer to do the uspace epp work :-/
[12:22:16] <seb_kuzminsky> i haven't read your branches yet, so i dont have a good opinion...
[12:22:51] <seb_kuzminsky> it goes rtos-uspace, rtos-uspace-apis, rtos-uspace-hm2-eth, is that right?
[12:23:50] <jepler> CaptHindsight: I don't have anything in mind after this.
[12:23:55] <jepler> seb_kuzminsky: right.
[12:24:33] <seb_kuzminsky> you think the rtos-uspace-hm2-eth branch breaks hm2-pci? but rtos-uspace{-apis} is merge-ready?
[12:24:48] <jepler> seb_kuzminsky: I'll look at that epp branch.
[12:25:11] <jepler> seb_kuzminsky: pretty sure about the first.
[12:25:56] <CaptHindsight> jepler: I ask since memleak was working on the diffs from UBC and separating out the features
[12:26:17] <CaptHindsight> is there anything else that he can do?
[12:26:45] <jepler> seb_kuzminsky: I am sure that you will find minor problems in the other two branches if you look. there is some kernel modparam business that I need to cure of ifdefness, and I need to guard all new headers with RTAPI_BEGIN/END_DECLS
[12:27:08] <seb_kuzminsky> jepler: i'll try to read it all on tuesday night
[12:27:57] <seb_kuzminsky> CaptHindsight: i dont think there's any need for heroic rebasing of ubc, but there's plenty of other work in linuxcnc that would really benefit from memleak's skills
[12:28:13] <jepler> CaptHindsight: if there are specific things that he wants in linuxnc, he could rebase them onto rtos-uspace-apis if he wants to try.
[12:28:29] <jepler> it's safe to say I am not aware of all that is in there...
[12:29:01] <jepler> (there=ubc/machinekit)
[12:29:38] <CaptHindsight> he's waiting for Paolo to fix the scheduler in RTAI then he'll work the newer kernels
[12:30:19] <seb_kuzminsky> we're having trouble with the 3.4.87 patch in rtai, both dgarr and i are getting repeatable kernel panics
[12:30:27] <seb_kuzminsky> (in case he's itching to get back to rtai ;-)
[12:31:20] <CaptHindsight> I'll see what he thinks about that panic issue
[12:32:30] <seb_kuzminsky> great, thanks!
[12:32:41] <seb_kuzminsky> he knows more about rtai than anyone else here
[12:34:03] <micges-dev> logger[mah]: hi
[12:34:03] <logger[mah]> micges-dev: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-06-30.html
[12:38:55] <micges-dev> jepler: yes hm2-eth will break hm2_pci becouse of tram.c modifications, I didn't figure out clean solution for this
[12:52:46] <jepler> micges-dev: OK
[12:53:29] <jepler> micges-dev: there must be some solution, but I'm not familiar enough with the code to propose one
[12:53:44] <jepler> for hm2_test, I made the new functions equal to the old functions, and also checked if the buffer was not NULL before using it
[12:54:00] <jepler> you can test whether a device has the new functions, just use the function pointer in a boolean context
[12:56:05] <jepler> if(hm2->llio->queue_read) { do what devices that support queue_read need } else { do what old devices like hm2_pci need }
[12:57:20] <micges-dev> yeah seems simple
[13:00:34] <jepler> if only everything could be simple
[13:00:59] <jepler> you know what would be cool: build the hostmot2 vhdl as a userspace app, and have it talk udp to hm2_eth
[13:01:07] <jepler> then you could test the whole hostmot2 in software
[13:01:58] <jepler> you'd want the hostmot2 vhdl to also be a hal component, so you could run it as a hal "fast thread"
[13:02:25] <jepler> I wonder if hostmot2 works right if you say its basic clock is .04MHz
[13:03:54] <micges-dev> nice idea
[13:04:29] <seb_kuzminsky> maybe the xilinx webpack stuff has an emulator?
[13:05:19] <jepler> I used ghdl to build a program that incorporated vhdl source code into a linux executable
[13:05:39] <jepler> it was only on a small fraction of the total hostmot2, though -- just the PIN file and a bit more
[13:06:09] <jepler> pinxml.py in the source of hostmot2-firmware, it's how I made the .xml description of the firmware's capabilities
[13:07:50] <jepler> I suspect it's more than a weekend project though
[13:08:24] <micges-dev> On the other way I'm extracting sserial code and encoder code into library which can be used from user space for one small project
[13:08:42] <jepler> neat!
[13:09:07] <micges-dev> I think it would be easier to make some automatic sort of tests of lib code with some boards
[13:10:56] <seb_kuzminsky> i didn't know about ghdl, looks neat
[13:11:45] <jepler> yes, a testing program that wasn't hostmot2's vhdl would also be useful
[13:11:50] <jepler> if your goal is to test the driver
[13:12:45] <seb_kuzminsky> it'd be good to test the vhdl too
[13:12:54] <jepler> I imagine tests for the velocity estimation, encoder rollovers, and those kinds of things: difficult to set up on real hardware, and probably buggy until tested to death
[13:13:12] <seb_kuzminsky> yeah, right
[13:13:27] <seb_kuzminsky> augh, stop thinking of awesome things i'll never get around to doing
[13:13:30] <jepler> hah
[13:13:41] <jepler> perhaps when you learn to fork and *not* exec, then you'll be able to get twice as much done
[13:13:52] <seb_kuzminsky> heh
[13:14:33] <seb_kuzminsky> i want brain uploading and editing, so i can treat my consciousness the wame way i treat my virtual machines
[13:14:39] <jepler> I don't need a new project either, this past week seems like more substantial linuxcnc work than I've done in recent memory
[13:14:56] <seb_kuzminsky> yeah, that's a good chunk of work for sure
[13:15:02] <seb_kuzminsky> hope to get it merged soon!
[13:17:03] <jepler> seb_kuzminsky: if you have some review items on tuesday, I'll add them to my todo list
[13:17:14] <seb_kuzminsky> aight
[13:17:20] <jepler> maybe after one more rebase I'll feel like it's ready
[13:17:48] <jepler> that reminds me, I am concerned about something I saw while looking at the arm port
[13:17:58] <jepler> we use <asm/bitops.h> in __KERNEL__
[13:18:15] <seb_kuzminsky> oh, the broken perf thing in glo's ubc is my fault, not the mk folks, they took it out and replaced it with something better that i dont know about
[13:18:21] <jepler> but other times we use the lock prefix, which is what <asm/sync_bitops.h> implement
[13:19:40] <jepler> seb_kuzminsky: oh, I'll take a look in machinekit and see what they came up with. Do you know, is it the performance counter that has to be enabled via a kernel module?
[13:20:03] <skunkworks> cradek, I cannot for the life of me get the usb image to boot on this GA-j1800n mother board (atom like) it end at the command line with 'unable to find media containing live file system'
[13:20:04] <jepler> .. that solution doesn't work for my chromebook, I can't figure out how/where to get module headers
[13:20:28] <seb_kuzminsky> i'm not sure what they ended up going with
[13:20:37] <skunkworks> The internet says swiching from 3.0 to 2.0 usb, boot order, legacy whatever... So far nothing is working.
[13:20:52] <skunkworks> hmm - I should see if it boots my 14.04 usb image
[13:21:55] <seb_kuzminsky> skunkworks: strange
[13:22:06] <seb_kuzminsky> the image booted fine in the one computer i tried it on
[13:22:17] <seb_kuzminsky> i just dd'ed the .iso to /dev/sdc (my usb stick)
[13:22:25] <skunkworks> 14.04 boots from usb
[13:22:32] <seb_kuzminsky> ruh roh
[13:23:01] <skunkworks> I should make sure my laptop still boots the weezey image.. (incase it is just borked)
[13:23:23] <skunkworks> seb_kuzminsky, that is exactly how I made the image.. (it booted on 2 other machines)
[13:24:32] <jepler> seb_kuzminsky: their rt-preempt.c _rtapi_get_clocks_hook seems to use CLOCK_MONOTONIC just like me
[13:25:35] <jepler> there's this thing which looks interesting but didn't work on my arm device: http://neocontra.blogspot.com/2013/05/user-mode-performance-counters-for.html
[13:25:44] <jepler> probably would work on bb / rpi where you can build kernel modules though
[13:29:42] <jepler> .. and maybe I could craft compatible-enough kernel headers myself. I should try it. http://neocontra.blogspot.com/2013/05/user-mode-performance-counters-for.html
[13:29:45] <jepler> oops
[13:29:45] <jepler> https://github.com/dnschneid/crouton/wiki/Build-kernel-headers-and-install-Virtualbox-(x86)
[13:35:39] <skunkworks> jepler, from reading back - there isn't a working -rt kernel for 14.04?
[13:45:29] <jepler> skunkworks: possibly not.
[13:48:45] <jepler> skunkworks: there's linux-image-lowlatency, but no -rt or -realtime apparently
[13:48:56] <skunkworks> ok
[13:48:59] <jepler> >>>
[13:48:59] <jepler> -lowlatency kernel - very similar to the -preempt kernel and based on the -generic kernel source tree, but uses a more aggressive configuration to further reduce latency. Also know as a soft real-time kernel.
[13:49:03] <jepler> -realtime kernel - is based on the vanilla kernel source tree with Ingo Molnar maintained PREEMPT_RT patch applied to it. Also know as a hard real-time kernel.
[13:49:18] <skunkworks> so I need to get wheezy booting
[13:49:21] <skunkworks> :)
[13:50:39] <jepler> you could try lowlatency and see what results you get
[13:50:58] <jepler> .. if only so we know not to bother trying any harder
[13:51:43] <jepler> according to the very outdated ubuntu wiki pages I've found, -lowlatency was giving latencies in the 3-4ms range, not particularly good for linuxcnc.
[13:51:46] <jepler> ms, not us
[14:01:58] <CaptHindsight> http://pastebin.com/S2dN6VVg What is the "regular acceleration limit MAX_ACCELERATION"? And how does this relate to the values in the trajectory section for DEFAULT_ACCELERATION and MAX_ACCELERATION?
[14:03:49] <CaptHindsight> what if you want one axis to have a far lower accel than whats in the Trajectory section of the .INI?
[14:06:20] <skunkworks> the axis takes precident.. So if You have the axis acc set to 1 - that is as fast as that axis will accelerate
[14:06:46] <skunkworks> jepler, thanks
[14:07:01] <skunkworks> The wheezy image boots off the cd
[14:07:07] <skunkworks> *dvd
[14:08:27] <skunkworks> Hmm - I think the issue is that wheezy doesn't see the usb subsystem... (mouse and keyboard don't work)
[14:09:26] <CaptHindsight> skunkworks: but does that note mean that STEPGEN_MAXACCEL to a few percent higher than the regular acceleration limit MAX_ACCELERATION of that same AXIS or of the trajectory planner?
[14:10:14] <jepler> skunkworks: is that with cradek's image, or with an official wheezy image?
[14:35:01] <skunkworks> jepler, cradeks image
[14:46:21] <skunkworks> jepler, I vaugly rememeber one of the older ubuntu livecd's having the same problem
[14:46:23] <skunkworks> maybe
[17:23:12] <cradek> [answering way back in time] yes that was on purpose at the time, because that's where I got the linuxcnc package. it should be no longer. added dialout to the initial groups (weird that they have both dip and dialout). what firware package(s) should I add? I wasn't sure they were up to date enough to bother...?
[17:32:09] <cradek> skunkworks_: for my very old machine with broken usb booting, I used "plop": http://www.plop.at/en/bootmanager/download.html
[17:32:29] <cradek> you put it on a cd, and then when you boot it, you can pick "usb" to boot the stick
[17:33:09] <cradek> I wonder if some bioses fail to boot images more than a cd's size or something
[17:34:07] <cradek> fwiw, I put the latest at www.linuxcnc.org/binary.hybrid.iso - md5sum 730f13ef0292712f599bd458276f5f10
[17:34:23] <cradek> bbl
[17:43:50] <seb_kuzminsky> cradek: i think you should include hostmot2-firmware-all on the iso
[17:44:12] <seb_kuzminsky> if you're short on space you could exclude the 4i6* and 3i20 packages
[17:59:02] <cradek> there is no space limitation
[18:06:44] <skunkworks_> cradek: this was a very new machine....
[18:31:00] <JT-Shop> I can't understand why Marius uses the requested velocity in the thcud calculation for correction amount
[18:31:32] <JT-Shop> to me it seems like each period you move some amount if correction is needed
[18:34:42] <JT-Shop> if I understand what is going on each period you could have a step, so in the comp you can't go more than one step each time
[18:35:14] <JT-Shop> because your not commanding Z to move while you cut you can hyjack the position by the max of one step per period
[18:35:22] <JT-Shop> I think this is correct
[18:36:02] <cradek> skunkworks_: well crap, I don't know what to suggest
[18:36:29] <JT-Shop> I think a problem happens when the comp removes the offset... in one direction it just changes the number but in the other direction it might try and step twice per period
[18:36:45] <cradek> I wonder if there are usb settings wrong, or we have usb drivers wrong in the kernel
[18:37:19] <cradek> skunkworks_: you might also try adding rootdelay=10 to the kernel command line
[18:37:40] <cradek> I had to do that for my machine that boots lvm from CF
[18:38:01] <cradek> if you find that fixes it, I bet I can add it by default and it'll only cost a few seconds.
[18:41:00] <skunkworks_> cradek: I will try it tomorrow
[18:41:25] <skunkworks_> it seemed to be something to do with usb - it seemed like it could not find the live partions
[18:51:59] <skunkworks_> cradek: this is a GB-j1800n-d2h
[18:52:03] <skunkworks_> google isn'
[18:52:11] <skunkworks_> isn't saying anything
[19:40:52] <cradek> skunkworks_: I hope the wait fixes it... seems like having root on something hotpluggy is tricky
[19:56:16] <cradek> skunkworks_: I was rebuilding anyway, so I added rootwait. it's a shot in the dark.
[20:09:40] <jepler> skunkworks_: as long as you don't care about meeting realtime deadlines, you could run the hm2-eth code on any old kernel
[21:04:07] <skunkworks_> well - I was hoping for realtime deadlines... :)
[21:23:04] <skunkworks_> cradek: did you see it booted the image burned to a dvd - but usb wasn't there?
[21:26:14] <CaptHindsight> 3.12.22-rt34 was running ~32uS, is that too slow?
[21:28:02] <cradek> no, I missed that
[21:28:14] <cradek> that was a very clever test
[21:28:54] <cradek> can you get a dmesg?
[21:35:08] <cradek> seb_kuzminsky: [hours later...] hostmot2-firmware-all installs but doesn't do anything. it pulls in no dependencies.
[21:41:48] <cradek> seb_kuzminsky: apt-cache showsrc hostmot2-firmware-all doesn't
[21:41:57] <cradek> W: Unable to locate package hostmot2-firmware-all
[21:41:58] <cradek> N: No packages found
[21:46:46] <skunkworks_> cradek: I can get a dmesg tomorrow
[21:47:37] <skunkworks_> I vaugly remember one of the ubuntu livecd's booting without usb on that motherboard...
[22:51:12] <seb_kuzminsky> ugh, the hostmot2-firmware situation is depressing
[22:52:21] <seb_kuzminsky> yep, sure enough, i see the same thing as cradek
[22:55:14] <seb_kuzminsky> oh, i fixed the hostmot2-firmware-all dependencies in... 0.8.10, available from the hm2 buildbot
[22:55:25] <seb_kuzminsky> but not from linux.org, sadly
[22:55:45] <seb_kuzminsky> should i push the 0.8.10 debs there? i think i should
[22:56:47] <skunkworks_> seb is talking to himself again...
[23:00:18] <seb_kuzminsky> who said that!?
[23:00:51] <seb_kuzminsky> are... are you my conscience?
[23:03:49] <skunkworks_> heh