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

Back
[03:08:51] <seb_kuzminsky> new linux + rtai debs here:
[03:08:54] <seb_kuzminsky> deb http://highlab.com/~seb/linuxcnc/rtai-debs/2014-06-25 wheezy main
[03:09:10] <seb_kuzminsky> for now it's just wheezy 32-bit
[03:09:51] <seb_kuzminsky> linuxcnc master builds & passes runtests for me with the 686-pae rtai kernel image in a vm, but i haven't tried moving metal with it yet
[03:10:30] <seb_kuzminsky> the kernel is 3.4.87, which is the latests supported by shabby's rtai repo as far as i know
[03:11:05] <seb_kuzminsky> rtai itself is a fairly old version, the tip of master didn't build for me, i'll be bisecting it in the coming days...
[03:11:43] <seb_kuzminsky> the rtai version is basically the same as the 3.4.55-rtai debs from before (since we know it works)
[03:21:59] <memfrob> seb_kuzminsky, master is a big mess
[03:22:11] <memfrob> i spent months on it..
[03:23:42] <memfrob> by basically the same, how do you mean?
[03:25:53] <memfrob> seb_kuzminsky, i wish you a lot of luck with the new master branch. its been the most difficult task i ever faced
[08:17:49] <jepler> seb_kuzminsky: +1
[09:56:58] <cradek> seb_kuzminsky: yes!!
[12:26:39] <memfrob> seb_kuzminsky, if you have any questions for me let me know in regards to master of RTAI
[12:28:08] <seb_kuzminsky> memfrob: are you memleak?
[12:32:02] <CaptHindsight> yes
[12:32:08] <seb_kuzminsky> heh
[12:32:14] <seb_kuzminsky> ok, cool, thanks
[12:34:05] <seb_kuzminsky> i'm currently building a0dc5355ee233032926dd23d1e132ef1befbbd76, plus a bunch of local debian packaging commits that i'm not ready to send a PR for yet, plus Lukas Anzinger's makefile parsing commit
[12:46:10] <memfrob> i just remembered one more bug in RTAI!
[12:46:23] <memfrob> one moment for the specific section
[12:47:14] <seb_kuzminsky> heh
[12:51:21] <memfrob> its the timer setup
[12:51:33] <memfrob> however that can possibly just be a specific board issue
[12:55:05] <memfrob> https://github.com/ShabbyX/RTAI/blob/master/base/sched/sched.c#L2811
[12:55:44] <memfrob> timer setup for me is stuck at 159 and when its there as opposed to 999 ns i've been having problems
[12:56:47] <memfrob> what affects the value of the timer setup i'm not sure but that value is supposed to be at 999 ns
[12:57:12] <seb_kuzminsky> hmm, ok
[12:57:13] <memfrob> (At least when the kernel timer freq is set to 1000 Hz)
[12:57:17] <seb_kuzminsky> i'll keep an eye out for it
[12:58:32] <memfrob> you can set the timer freq in the kernel config menu under processor type and features, its near the bottom of that menu.
[13:00:09] <memfrob> seb_kuzminsky, for RTAI did you just add the 3.4.87 kernel patch to base/arch/x86/patches and do you know the IPIPE release for that?
[13:00:18] <memfrob> is it -4, -1, -3, etc?
[13:01:22] <memfrob> i.e. hal-linux-3.4.87-X(ipipe release)-x86.patch
[13:02:08] <seb_kuzminsky> the linux-image i built is using the kernel patch from the tip of shabby's master, but the rtai modules are using that older commit (a0dc5355e)
[13:02:24] <memfrob> i tried -3 and -4 releases and those wouldn't work for me in the a0dc5355ee commit
[13:03:01] <memfrob> thats -4 wow!
[13:03:24] <memfrob> see thats one of the reasons i got fed up with RTAI is that i couldnt tell what issues were upstream and what problems were just board specific for me
[13:03:56] <memfrob> if latency-test works for you with -4 then my specific board is broken with -4 with a0dc5355ee commit
[13:04:22] <seb_kuzminsky> memfrob: i'm using the patch called hal-linux-3.4.87-x86-4.patch
[13:04:50] <memfrob> yes thats -4 which doesnt work for me
[13:05:05] <memfrob> i would get hard locks every minute, sometimes even less
[13:05:18] <memfrob> forced to reboot
[13:05:33] <seb_kuzminsky> that kernel patch (applied to 3.4.87) is passing the linuxcnc runtests and the rtai tests (kern/{latency,preempt,switches})
[13:05:44] <memfrob> thats interesting it works for you
[13:05:50] <seb_kuzminsky> in a virtual machine
[13:06:07] <memfrob> goes to show that in order to work on RTAI you need a bunch of boards to test every single patch on
[13:06:19] <seb_kuzminsky> yeah...
[13:06:21] <cradek> yuck
[13:06:38] <memfrob> luckily im fed up with RTAI and dont need to touch it anymore
[13:07:35] <memfrob> i might join xenomai actually as much as i previously hated it
[13:08:29] <memfrob> hello micges!
[13:08:36] <micges> ahoy
[13:08:55] <micges> what's up?
[13:09:07] <seb_kuzminsky> memfrob: i'm pretty excited about rt-preempt
[13:09:19] <memfrob> thanks for all that heavy lifting with hm2-ethernet
[13:09:36] <memfrob> you are? why is that?
[13:10:22] <memfrob> if you're trying to run a fast machine with fancy expensive hardware it lacks
[13:10:30] <micges> memfrob: it's not the end of journey but driver is working stable
[13:10:38] <memfrob> s/with/without/
[13:11:36] <memfrob> ah that reminds me! in order for me to seperate xenomai + preempt-rt from the rest of the ubc-3 branch i need to remove the 7i80 / rt-net stuff because the merge is too big and confusing me
[13:12:22] <memfrob> if i separated the ubc-3 branch from the git mah priv server would that be ok?
[13:13:02] <memfrob> merging in ubc3-7i80 into master just includes too much stuff and i cant tell what belongs where
[13:13:19] <memfrob> which stand-alone ubc-3 branch should i use?
[13:14:00] <micges> memfrob: why you want to merge ubc3-7i80 to master?>
[13:15:17] <memfrob> micges, not specifically. linuxcnc devs want xenomai and preempt-rt seperated from the rest of mhab's changes such as beaglebone black, etc
[13:16:28] <memfrob> in order to do that i need more of a baseline of ubc-3 without additional changes on top of that such as hm2-eth
[13:17:12] <micges> I used latest ubc3 available and added just hm2_eth stuff
[13:17:39] <memfrob> latest ubc3 available, do you mean from git.linuxcnc or git mah priv?
[13:17:52] <micges> from git.linuxcnc.org
[13:17:52] <memfrob> because git mah priv has newer ubc3 code
[13:18:15] <seb_kuzminsky> bbl, lunch
[13:18:54] <memfrob> ah so i can just merge ubc-3 to master then isolate the rtapi code, ok
[13:19:23] <micges> I don't know in what shape ubc3 is atm
[13:20:12] <micges> it was working for me (hm2_eth) so I didn't pay much attention
[13:24:00] <memfrob> currently from what i see ubc-3 hasnt changed much since ubc3-7i80
[13:24:09] <memfrob> just v2.5 merges and various fixes outside of rtapi
[13:26:57] <memfrob> in which case is that accepted?
[13:28:43] <memfrob> (for me to separate xenomai and preempt-rt from rest of mhab's changes based on latest ubc-3 branch)
[13:29:51] <CaptHindsight> micges: but we also want to merge your 7i80 into master as well
[13:30:04] <CaptHindsight> your additions
[13:30:42] <CaptHindsight> but one step at a time so we can test it
[13:32:47] <memfrob> yeah that's what i meant, its hard to express myself at times
[13:33:06] <memfrob> @ micges
[13:41:30] <jepler> seb_kuzminsky: what's the procuedure for pushes to 2.6 right now? I have some stuff I think is safe bugfixing, but it doesn't fix any user-visible problems
[13:41:46] <jepler> seb_kuzminsky: fixing configure for systems which happen to have more than one version of tcl-dev / tk-dev (pick latest one)
[13:41:56] <jepler> seb_kuzminsky: fixing rtapi_print_msg's argument type to msg_level_t instead of int level
[13:42:10] <memfrob> jepler, while working on configure can you add rsyslog and tkimg?
[13:42:10] <jepler> seb_kuzminsky: not linking two copies of liblinuxcnchal to milltask
[13:42:26] <jepler> seb_kuzminsky: and getting rid of a #define that's never used
[13:42:51] <memfrob> i use gentoo and i need to manually install these to run linuxcnc
[13:42:54] <cradek> memfrob: we don't use syslog
[13:42:56] <jepler> memfrob: rsyslog?
[13:43:09] <memfrob> sudo make log requires rsyslog..
[13:43:16] <memfrob> and it tells me to run sudo make log
[13:43:21] <jepler> are you talking about something that is in 2.6 branch?
[13:43:47] <jepler> memfrob: are you talking about something that is in 2.6 branch?
[13:44:01] <memfrob> either that or master
[13:44:20] <memfrob> tkimg at least though is required for 2.5 2.6 and master though
[13:45:51] <memfrob> its used to generate the GUI IIRC
[13:46:25] <jepler> I'm aware that tkimg is required and only debian dependencies pull it in
[13:46:32] <jepler> I am asking about this log thing you mentioned
[13:46:35] <jepler> as far as I know that's not in 2.6 or master
[13:46:41] <jepler> it is in the branch that is unlikely to be merged
[13:47:38] <memfrob> which branch would that be?
[13:47:58] <memfrob> ah you know what.. thats in the ubc-3 branches like ubc3-7i80
[13:48:05] <memfrob> sorry about that..
[13:49:04] <memfrob> if tkimg is required then it should be asking for upon configure as opposed to telling the person to install it after failing to open the machine control interface
[13:53:14] <jepler> in theory isn't it possible to run keystick and not require img::png ?
[13:53:21] <jepler> it's certainly not required to build the software
[13:54:04] <jepler> well, shrug, possibly this screws up more actual users compared to the zero keystick-only users
[13:54:39] <memfrob> XD
[13:57:20] <jepler> well since seb isn't telling me "no", probably because he's AFK, I'll push this stuff in a sec
[14:05:58] <memfrob> <seb_kuzminsky> bbl, lunch
[14:08:16] <jepler> OK, I'll give him a few more minutes to finish eating
[14:10:04] <memfrob> om nom nom
[14:17:08] <micges> CaptHindsight: memfrob: I'll happly merge hm2_eth to master when rt-preempt will be supported, I'll finish driver soon
[14:17:49] <CaptHindsight> micges: ok, so we should just ignore that and let you do it when you're done
[14:18:21] <micges> yeah I think so
[14:18:50] <memfrob> so all that blackberry stuff will be merged too, correct?
[14:19:06] <memfrob> black rasperry pi whatever its called
[14:19:06] <CaptHindsight> micges: ok, is there anything else in there besides the hm2_eth that you did?
[14:19:21] <micges> no
[14:19:39] <CaptHindsight> memfrob: I think the BBB (beaglebone black) stays out for now
[14:19:41] <micges> if there is any rtnet stuff in there, you can drop it
[14:20:18] <memfrob> right beaglebone black.. so micges you're going to separate it?
[14:20:58] <memfrob> because BBB is currently in ubc3-7i80 branch..
[14:21:10] <CaptHindsight> micges: we want to merge support for the three real time kernels first
[14:21:33] * memfrob is so lost right now
[14:21:39] <CaptHindsight> memfrob: then I think micges will merge the hm2_eth
[14:21:45] <jepler> a lot of different people have competing goals and competing ideas about how to get there
[14:21:45] <memfrob> ohh!!
[14:22:26] <CaptHindsight> trying to get consensus here
[14:22:38] <memfrob> jepler, i was under the impression we would get JUST RTOS support merged from ubc3
[14:22:45] <jepler> personally, I would like to see a branch which *only* adds a POSIX userspace rtapi implementation
[14:22:56] <memfrob> ok so we ARE on the same page :)
[14:23:38] <jepler> I think that is a first step on which the hm2_eth stuff builds, and if there's still sufficient interest by people who want to contribute to linuxcnc it is also a place to do the ARM porting work
[14:23:40] <seb_kuzminsky> jepler: if it fixes bugs, please push it to 2.6
[14:24:06] <CaptHindsight> yes, ARM can be next, there is interest
[14:24:28] <jepler> also a userspace PCI implementation could be built in after POSIX userspace
[14:24:54] <CaptHindsight> and not just for the BBB ARM, other ARM boards as well
[14:24:54] <CaptHindsight> but that is not high priority
[14:25:03] <CaptHindsight> we probably want to test the hell out of it first
[14:25:31] <jepler> fwiw I have been working for about a week on a different POSIX userspace rtapi implementation, but I haven't run it against a -rt kernel yet to see if it actually performs
[14:26:51] <CaptHindsight> jepler: the first goal is to separate out all the useful bits from ubc3-7i80
[14:27:01] <KGB-linuxcnc> 03Jeff Epler 052.6 619a88b 06linuxcnc 10src/configure.in configure: Choose highest-numbered version of tcl/tk * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=619a88b
[14:27:01] <KGB-linuxcnc> 03Jeff Epler 052.6 6b1e3e1 06linuxcnc 10(6 files) rtapi: use proper type for rtapi_print_msg level * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b1e3e1
[14:27:01] <KGB-linuxcnc> 03Jeff Epler 052.6 e00342a 06linuxcnc 10src/rtapi/sim_common.h Remove unused define * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e00342a
[14:27:02] <KGB-linuxcnc> 03Jeff Epler 052.6 c2cf146 06linuxcnc 10src/emc/task/Submakefile milltask: don't link with ULAPISRCS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2cf146
[14:27:06] <KGB-linuxcnc> 03Jeff Epler 052.6 b42f36d 06linuxcnc 10src/configure.in configure: make missing img::png a configure-time failure * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b42f36d
[14:27:12] <CaptHindsight> 1) new real time kernel support
[14:27:26] <CaptHindsight> 2) hm2_eth
[14:27:32] <CaptHindsight> 3) ARM
[14:27:35] <linuxcnc-build_> build #329 of 1400.rip-wheezy-i386 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/329 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:41] <jepler> uh oh! I broke it!
[14:27:46] <CaptHindsight> 4) whatever else looks useful
[14:27:47] <linuxcnc-build_> build #330 of 1401.rip-wheezy-amd64 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/330 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:27:48] <jepler> so much for simple bugfixes
[14:28:12] <cradek> that's a nice fast failure
[14:29:08] <KGB-linuxcnc> 03Jeff Epler 052.6 537a1e8 06linuxcnc 10debian/control.in packaging: must build-depend on what configure checks for * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=537a1e8
[14:31:49] <linuxcnc-build_> build #1376 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1376 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:32:38] <jepler> seb_kuzminsky: thanks again for buildbot
[14:32:39] <linuxcnc-build_> build #2172 of 1300.rip-precise-i386 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2172 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:33:10] <linuxcnc-build_> build #2174 of 1306.rip-precise-amd64 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2174 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:33:25] <linuxcnc-build_> build #1970 of 1901.clang-precise-amd64 is complete: Failure [4failed configuring] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/1970 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:58:11] <seb_kuzminsky> thanks jepler
[15:06:13] <linuxcnc-build_> build #2176 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2176 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:21:21] <jepler> eep how bad did I hurt buildbot with that commit?
[15:22:22] <seb_kuzminsky> it just likes to complain a lot
[15:23:28] <jepler> it's the part where buildbot ragequit the channel that has me worried
[15:23:31] <seb_kuzminsky> oh, the disconnect? i think there was a brief power outage at my house and i think my dsl router thingy isn't properly hooked up to my ups
[15:23:47] <seb_kuzminsky> skunkworks too
[15:24:35] <jepler> apparently so
[15:25:13] <jepler> hmmm if I hadn't insisted on merging two files and renaming some others, I think this POSIX rtapi implementation would have been quite small in terms of lines changed
[15:25:23] <jepler> as it is, 44 files, 1481 insertions, 1267 deletions
[15:27:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 715e91f 06linuxcnc 10(11 files in 2 dirs) rtapi: rename "sim" to "uspace" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=715e91f
[15:27:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 21bfde3 06linuxcnc 10(14 files in 7 dirs) rtapi: use defined(__KERNEL__) to test for kernel space * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21bfde3
[15:27:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace a7d2e7c 06linuxcnc 10(13 files in 8 dirs) configure: Change "sim" to "uspace", with fallout elsewhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7d2e7c
[15:27:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace fc8c477 06linuxcnc 10debian/rules.in 10src/Makefile rtapi_app: setuid permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc8c477
[15:28:00] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 3f22058 06linuxcnc 10(5 files) packaging: linuxcnc-uspace, not linuxcnc-sim * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f22058
[15:28:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace a7f2110 06linuxcnc 10src/rtapi/uspace_rtapi.c 10src/rtapi/uspace_rtapi_app.cc rtapi_app: do commands based on a callback * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7f2110
[15:28:08] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 2c5ac28 06linuxcnc 10src/rtapi/Submakefile 04src/rtapi/uspace_rtapi.c 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: roll uspace_rtapi.c into rtapi_app.cc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c5ac28
[15:28:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace f064c19 06linuxcnc 10src/rtapi/rtai_rtapi.c 10src/rtapi/rtapi.h 10src/rtapi/rtl_rtapi.c 10src/rtapi/uspace_rtapi_app.cc rtapi: clock period should be in unsigned longs everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f064c19
[15:28:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 38989db 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Introduce class RtapiApp and implementation Pth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=38989db
[15:28:20] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace dcb60b3 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: use POSIX scheduler priorities * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcb60b3
[15:28:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace bed96ec 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Drop rtapi_task_set_period API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bed96ec
[15:28:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 892ff8d 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: task_new is thread-agnostic * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=892ff8d
[15:28:33] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace a10e118 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Delete "rtapi_task_stop", it's never used * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a10e118
[15:28:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 6e64c0a 06linuxcnc 10src/hal/Submakefile 10src/rtapi/Submakefile 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Implement posix realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e64c0a
[15:28:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace c968688 06linuxcnc 10src/rtapi/uspace_common.h uspace-rtapi: get time in nanoseconds, not microseconds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c968688
[15:28:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 579363c 06linuxcnc 10src/.gitignore 10src/Makefile build: optionally automatically invoke 'sudo make setuid' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=579363c
[15:28:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace f4a9990 06linuxcnc 10(5 files in 3 dirs) uspace-rtapi: get rid of use of GNU pth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4a9990
[15:28:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 4fa4c13 06linuxcnc 10src/rtapi/uspace_common.h uspace-rtapi: lock and page in shared memory segments * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4fa4c13
[15:29:29] <jepler> feedback welcome
[15:29:37] <jepler> like I mentioned, I haven't actually tried it on a -rt kernel yet
[15:29:49] <jepler> it passes tests on non-rt kernels though
[15:30:37] <cradek> happy happy
[15:31:38] <jepler> also I should mention that it's based on 2.6, not master
[15:32:00] <cradek> I bet it doesn't matter
[15:32:08] <jepler> it auto merges at the moment
[15:32:13] <cradek> cool
[15:35:06] <jepler> I think that either the userspace PCI library or the hm2-eth stuff would be cool to try on top of this branch
[15:35:38] <cradek> does it run parport (etc) as-is?
[15:35:41] <jepler> when redoing the pci stuff, I would prefer to see all the APIs prefixed and types prefixed with rtapi_ -- in kernel space, just #define rtapi_pci_foo to pci_foo, and in userspace define rtapi_pci_foo
[15:35:55] <cradek> that sounds smart
[15:36:03] <jepler> cradek: no, because parport also uses kernel APIs for getting parport info
[15:36:17] <cradek> oh, ok
[15:36:23] <cradek> serport might work
[15:36:49] <jepler> there's some kind of "sim parport" at src/hal/simdrivers/uparport.c that may do actual I/O in userspace, not sure
[15:36:49] <cradek> (I'm just wondering if we could test this right now)
[15:36:59] <jepler> yeah, the test machine I have has a serial port
[15:37:04] <jepler> with any luck, I'll scope some waveforms on it tonight
[15:37:09] <jepler> I'll come up with something
[15:37:18] <cradek> I'll help any way I can
[15:37:36] <jepler> right now it still doesn't build serport or any other traditional hardware drivers
[15:37:44] <jepler> though there is an implementation of rtapi_outb / inb which should be right
[15:41:13] <cradek> rtapi_clock_set_period() returns unsigned long, but returns -EINVAL on error
[15:41:27] <cradek> is that broken?
[15:41:47] <jepler> huh good question
[15:42:11] <jepler> I only reasoned that it doesn't make sense to pass a negative period to rtapi_clock_set_period
[15:42:14] <jepler> I didn't think about error returns
[15:42:54] <jepler> it certainly means you can't check the return value for < 0
[15:43:10] <cradek> yeah, and I didn't check to see if anything does that
[15:44:11] <jepler> curr_period = rtapi_clock_set_period(period_nsec); if(curr_period < 0) ...
[15:44:14] <jepler> so yup
[15:44:32] <jepler> I guess I should make it "long"
[15:44:37] <cradek> is it true that fast can't ever interrupt slow threads now? if so that seems serious
[15:44:55] <jepler> that commit message must not be clear if it gave that impression
[15:45:21] <jepler> there are now two scenarios possible in userspace: POSIX threads sheduled with SCHED_FIFO or with SCHED_OTHER
[15:45:44] <jepler> with SCHED_FIFO, fast interrupts slow but not vice versa (rate monotonic scheduling). this requires sudo make setuid.
[15:46:12] <jepler> with SCHED_OTHER, nothing interrupts nothing. this is how rtapi_app runs without sudo make setuid, and incidentally is the way that sim with pth always worked
[15:46:48] <cradek> oh, ok
[15:47:22] <jepler> (in both cases, all the realtime threads have affinity for a single processor, so they also can't get scheduled concurrently)
[15:47:56] <cradek> that's the known safe thing we've always had, right?
[15:48:43] <jepler> Yes, I think it's approximately the same guarantee we had on RTAI with UP and RTAI with SMP when we set the CPU affinity.
[15:49:09] <jepler> it passes that threads.0 test when the run is extended to minutes and minutes
[15:49:18] <cradek> nice
[15:50:06] <jepler> .. but so does SCHED_OTHER *without* the mutex but with CPU affinity, which I strongly believe is a flawed setup, so the test is not perfect at detecting this undesired slow-interrupts-fast condition
[15:51:01] <jepler> it detects slow-concurrent-with-fast-on-different-CPUs condition readily
[16:06:07] <jepler> cradek: do you think I should improve that commit message so the trade-off of SCHED_OTHER is clearer?
[16:06:38] <jepler> cradek: (thanks for looking at my commits)
[16:06:47] <jepler> bbl
[16:13:26] <cradek> I see the "(without root privs)" now and that makes it clearer
[16:13:29] <cradek> I bet it's fine
[16:41:27] <jepler> nobody reads those anyway
[18:49:47] <memfrob> i got the complete diff now: https://raw.githubusercontent.com/NTULINUX/linuxcnc/master/ubc3-merge.diff
[18:54:23] <memfrob> thats master vs ubc-3
[18:57:39] <micges> you could remove docs and config and gcode changes, would be much smaller to dig in
[18:59:47] <memfrob> thanks for the tip, will do
[19:02:47] <memfrob> i also accidentally wrote over master..
[19:47:21] <linuxcnc-build> build #315 of 3003.dsc-wheezy is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3003.dsc-wheezy/builds/315 blamelist: Jeff Epler <jepler@unpythonic.net>
[19:57:18] <linuxcnc-build> build #1738 of 3001.dsc-lucid is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3001.dsc-lucid/builds/1738 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:10:55] <linuxcnc-build> build #2178 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2178 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:17:50] <linuxcnc-build> build #561 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/561 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:31:53] <skunkworks_> jepler: if you have anything you would like to test on a lot of hardware - I am game. (posix stuff)
[20:34:01] <linuxcnc-build> build #1726 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1726 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:06:55] <linuxcnc-build> build #316 of 3003.dsc-wheezy is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3003.dsc-wheezy/builds/316
[21:12:55] <linuxcnc-build> build #1739 of 3002.dsc-precise is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3002.dsc-precise/builds/1739
[21:16:54] <linuxcnc-build> build #1739 of 3001.dsc-lucid is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3001.dsc-lucid/builds/1739
[21:30:19] <linuxcnc-build> build #2179 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2179
[21:31:35] <linuxcnc-build> build #562 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/562
[21:47:06] <linuxcnc-build> build #1727 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1727
[22:05:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace fdcaeef 06linuxcnc 10debian/rules.in 10src/Makefile rtapi_app: setuid permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fdcaeef
[22:05:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 9ee9987 06linuxcnc 10(5 files) packaging: linuxcnc-uspace, not linuxcnc-sim * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ee9987
[22:05:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 8883c7a 06linuxcnc 10src/rtapi/uspace_rtapi.c 10src/rtapi/uspace_rtapi_app.cc rtapi_app: do commands based on a callback * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8883c7a
[22:05:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 37bec6e 06linuxcnc 10src/rtapi/Submakefile 04src/rtapi/uspace_rtapi.c 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: roll uspace_rtapi.c into rtapi_app.cc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37bec6e
[22:05:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 7176a8e 06linuxcnc 10src/rtapi/rtai_rtapi.c 10src/rtapi/rtapi.h 10src/rtapi/rtl_rtapi.c 10src/rtapi/uspace_rtapi_app.cc rtapi: clock period should be in unsigned longs everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7176a8e
[22:05:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 6529df0 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Introduce class RtapiApp and implementation Pth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6529df0
[22:05:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 85f4872 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: use POSIX scheduler priorities * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85f4872
[22:05:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 2f3e000 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Drop rtapi_task_set_period API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f3e000
[22:05:42] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 361143b 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: task_new is thread-agnostic * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=361143b
[22:05:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 5bf54e8 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Delete "rtapi_task_stop", it's never used * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bf54e8
[22:05:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 032aeb6 06linuxcnc 10src/hal/Submakefile 10src/rtapi/Submakefile 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc uspace-rtapi: Implement posix realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=032aeb6
[22:05:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace ca25266 06linuxcnc 10src/rtapi/uspace_common.h uspace-rtapi: get time in nanoseconds, not microseconds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca25266
[22:05:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace 6998818 06linuxcnc 10src/.gitignore 10src/Makefile build: optionally automatically invoke 'sudo make setuid' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6998818
[22:06:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace c04ed15 06linuxcnc 10(5 files in 3 dirs) uspace-rtapi: get rid of use of GNU pth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c04ed15
[22:06:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace e7b2840 06linuxcnc 10src/rtapi/uspace_common.h uspace-rtapi: lock and page in shared memory segments * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7b2840
[22:11:16] <memfrob> jepler, nice!
[22:11:59] <jepler> memfrob: having buildbot try the package building process again
[22:12:22] <jepler> I won't get to running it on real hardware with an -rt kernel yet tonight
[22:16:46] <jepler> well I didn't do a very good job of getting rid of pth
[22:17:05] <jepler> no doubt more failure messages from buildbot will be forthcoming
[22:21:45] <jepler> actually, I lied -- after 3 minutes of linuxcnc latency-test, max jitter of ~16us is reported
[22:22:14] <jepler> running with default 1ms / 25us threads
[22:23:31] <cradek> ooh
[22:23:42] <cradek> on a factory debian kernel?
[22:23:51] <jepler> 3.2.0-4-rt-amd64
[22:23:56] <cradek> that's awesome
[22:24:09] <jepler> I think it's typical of what rt-preempt is supposed to furnish
[22:24:20] <jepler> it's gratifying that I got decent results on the first real run
[22:24:27] <cradek> I'll say
[22:25:04] <jepler> maybe tomorrow I'll be able to toggle a bit on the serial port and scope it
[22:25:07] <jepler> 'night
[22:59:21] <linuxcnc-build> build #294 of 4016.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-amd64/builds/294 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[22:59:54] <linuxcnc-build> build #294 of 4015.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-i386/builds/294 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:01:25] <seb_kuzminsky> wow, that's great jepler
[23:03:45] <memfrob> jepler, you added preempt-rt to master?
[23:03:52] <memfrob> not master.. the other branch, sorry.
[23:04:04] <memfrob> the userspace rt branch.. that was preempt that you added?
[23:04:27] <memfrob> if so then the split i was doing was a waste of time lol.
[23:08:53] <seb_kuzminsky> memfrob: i've only been paying a little attention to what jeff's hacking on, but i think he did not add preempt-rt support, exactyl
[23:09:43] <seb_kuzminsky> i think he added support for what ubc calls 'posix', ie, non-sim using only posix soft-realtime extensions
[23:10:18] <seb_kuzminsky> i think (but i dont know for sure) that the rt-preempt kernel does a better job of implementing posix soft-realtime than the non-preempt-rt kernels do
[23:10:24] <memfrob> ohhhhhhhhh
[23:11:11] <seb_kuzminsky> i also think (but dont know for sure) that preempt-rt adds extensions on top of posix.1b that give even better realtime performance, but now i'm way out on a limb
[23:13:09] <linuxcnc-build> build #1725 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/1725 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:14:53] <linuxcnc-build> build #1731 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/1731 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:17:56] <linuxcnc-build> build #1731 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1731 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:28:47] <linuxcnc-build> build #563 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/563 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:35:06] <linuxcnc-build> build #1726 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/1726 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[23:45:09] <linuxcnc-build> build #1728 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1728 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>