Back
[09:51:20] <memleak> hi, does linuxcnc use rtai_mq (posix like message queues in RTAI)
[09:58:38] <jepler> memleak: no file in linuxcnc includes rtai_mq.h
[10:00:41] <memleak> i fixed the scheduler!
[10:00:54] <memleak> it was in-kernel RTAI code
[10:01:20] <memleak> rtai_sched_affinity was hosed
[10:02:10] <memleak> now im not getting realtime delays outside of what appears to be a low-latency latency-test
[10:02:18] <memleak> and no system hick ups either
[10:02:24] <memleak> this is perfect!
[10:02:37] <memleak> no need for ancient checkouts of RTAI anymore!
[10:03:03] <memleak> also the "last interval" column actually updates as fast as it used to
[10:03:38] <memleak> rtapi threads now close a lot quicker too, without delays, no system freezes... im stunned.
[10:04:14] <memleak> now to update the rtai github tree and clean the fix up
[10:04:23] <jepler> I'll be interested to see what you found
[10:04:48] <memleak> :DDDDDD
[10:22:41] <memleak> i can compile linuxcnc with 4 cores again too...
[10:31:10] <jepler> it looks like the mating distance of these connectors is close enough to .25in that a commonly-available standoff should do nicely
[10:31:15] <jepler> that's happy-making
[10:32:08] <jepler> bbl
[10:50:52] <memleak> thats odd i cant reproduce it now :/
[11:01:51] <memleak> oh thats why, heh i installed a wrong RTAI to /usr/realtime
[11:06:22] <Tom_itx> jepler, if they're metric it'll bend the pins
[11:26:53] <memleak> it worked for a second...
[11:27:11] <memleak> im really getting aggrivated im takin a break from this crap
[11:45:23] <jepler> Tom_itx: .25in is just a little more than the "correct" mating distance (5%)
[11:45:37] <jepler> (6mm)
[11:53:11] <Tom_itx> i just mentioned it because i've had board regrets before
[12:00:08] <jepler> Tom_itx: yeah, I'm thinking about it now because I did not initially have enough respect for the fragility of these 2mm connectors. apparently I shouldn't have done this:
http://emergent.unpythonic.net/files/sandbox/IMG_20140823_150751_027.jpg
[12:00:55] <jepler> new "under" board will have 4 mounting holes to match the main board so it doesn't misalign like that
[12:03:20] <Tom_itx> if you're gonna redo it and add mounts i'd change to the correct plug too
[12:04:03] <jepler> if you mean the way it's connected to the board in the background, that's unrelated jank
[12:04:27] <Tom_itx> no
[12:04:32] <Tom_itx> the underside plug
[12:04:38] <Tom_itx> pin spacing
[12:05:15] <jepler> the female receptacle and the pin header are both 2mm pitch
[12:05:25] <Tom_itx> ahh ok
[12:05:39] <Tom_itx> i thought you were trying to force a .1 plug
[12:05:50] <jepler> no, the slant is just because that's how gravity made it sit
[12:05:55] <Tom_itx> right
[12:06:11] <jepler> it's a 2x2 and a 2x4 with 2mm pitches, I don't think there'd be any way to force .100 into it
[12:06:38] <Tom_itx> you'd be surprised what some will try :D
[12:10:11] <jepler> pcw_home: just found the fedex door tag from that board you shipped me.. so I'll have it in my hands monday.
[12:24:29] <pcw_home> I guess you can't check it yet with your 2mm connector issues :-(
[12:26:08] <jepler> pcw_home: nope, more waiting
[12:26:10] <KGB-linuxcnc> 03Jeff Epler 05master 4be377e 06linuxcnc Merge branch 'jepler/proposed-master' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4be377e
[12:27:16] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master ef8d52c 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh interp: use strings to avoid buffer hell * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ef8d52c
[12:27:16] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 859e90b 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=859e90b
[12:27:35] <jepler> pcw_home: but since I had succeess with the 7i43, except for the latency issue, I know I'm in a good place to start working on a userspace SPI driver when all the hardware is lined up again
[12:28:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master ef8d52c 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh interp: use strings to avoid buffer hell * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ef8d52c
[12:28:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 859e90b 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=859e90b
[13:27:12] <linuxcnc-build> build #2358 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2358 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:30:07] <linuxcnc-build> build #2156 of 1901.clang-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2156 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:30:17] <linuxcnc-build> build #151 of 1102.rip-hardy-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/151 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:30:18] <linuxcnc-build> build #546 of 1405.rip-wheezy-armhf is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/546 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:30:33] <linuxcnc-build> build #2366 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/2366 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:30:55] <linuxcnc-build> build #2361 of 1100.rip-hardy-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/2361 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:33:17] <jepler> oh foo
[13:33:37] <jepler> .. I'll fix it shortly
[13:34:31] <jepler> hm I guess it was confused by a forced push I did?
[13:38:49] <linuxcnc-build> build #2359 of 1200.rip-lucid-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2359 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:44:37] <linuxcnc-build> build #2358 of 1300.rip-precise-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2358 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:46:00] <linuxcnc-build> build #2360 of 1306.rip-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2360 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[13:48:39] <linuxcnc-build> build #1560 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1560 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:01:00] <linuxcnc-build> build #2359 of 1202.rip-lucid-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2359 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:02:18] <linuxcnc-build> build #2359 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2359 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:02:20] <linuxcnc-build> build #516 of 1403.rip-wheezy-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/516 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:03:03] <linuxcnc-build> build #707 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/707 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:04:29] <linuxcnc-build> build #516 of 1400.rip-wheezy-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/516 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:04:49] <linuxcnc-build> build #27 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/27 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:06:58] <linuxcnc-build> build #172 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/172 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:06:58] <linuxcnc-build> build #2365 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2365 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>, Chris Radek <chris@timeguy.com>
[14:40:43] <memleak> ok scheduler is fixed again
[14:43:09] <memleak> https://github.com/NTULINUX/RTAI/commit/e53f8388491a99acf2e99bcc3522daa18767feb4
[14:43:17] <memleak> ah and my timer is showing up properly in dmesg!
[14:46:59] <memleak> i dont think i need 8259 code in there.. at least not in hal_64.c
[14:55:52] <jepler> which part of that change was the real aha for you? and how much is the performance improved?
[14:56:52] <memleak> well stripping out the 8259 code and moving the rtai_critical_exit(flags); back to their usual spots break that commit and bring it back to where it was
[14:56:59] <memleak> and the performance is night and day
[14:57:30] <memleak> maybe just strip out the 8259 code this time... that code is so sensitive..
[14:58:58] <memleak> extremely sensitive to breakage.
[15:02:53] <memleak> ok that worked.. now little by little im going to revert portions of that patch
[15:04:08] <memleak> jepler, whats a good way to do something like this with git? git revert / make only minimum required changes, or should i write on top of that commit?
[15:10:25] <memleak> looks to be the position of critical_exit functions
[15:10:31] <memleak> not 100% sure yet
[15:10:57] <jepler> memleak: you can "git revert --no-commit" the commit you want to play with
[15:11:06] <jepler> memleak: commit a smaller part of it, then "git stash" the rest
[15:11:39] <jepler> (that's if you want to think about partially reverting the commit)
[15:11:44] <memleak> would git stash hide it from github?
[15:11:54] <jepler> until you "git push" nothing on github changes
[15:11:59] <memleak> well obviously
[15:12:26] <memleak> git revert though shows up as "revert commit blah blah blah"
[15:12:36] <jepler> git revert --no-commit doesn't create a commit
[15:12:42] <memleak> oh...
[15:12:50] <memleak> awesome i hate those!
[15:14:14] <jepler> more suggestions from the internet:
http://stackoverflow.com/questions/4795600/reverting-part-of-a-commit-with-git
[15:15:00] <jepler> you could also revert to back before the commit, git cherry-pick --no-commit it, then commit the parts you want to try and stash the rest
[15:15:26] <jepler> (that's if you want to think about making a smaller commit, and if you are happy with pushing a commit that rewrites history)
[15:15:40] <jepler> (revert with "git reset --hard")
[15:16:48] <memleak> yup its the position of rtai_critical_exit
[15:16:53] <jepler> (I used "revert" in its non-technical sense)
[15:17:36] <memleak> thats so odd...
[15:17:46] <memleak> figured it'd be more than just one line of code..
[15:20:30] <jepler> which version did this problem get added in? Does it affect back to the one we're shipping with debian wheezy?
[15:21:04] <memleak> depends which checkout of RTAI
[15:22:30] <memleak> im using gentoo so i have no idea
[15:22:36] <jepler> base/arch/x86/hal/hal_x86.c- rt_release_irq(RTAI_APIC_TIMER_IPI);
[15:22:36] <jepler> base/arch/x86/hal/hal_x86.c: rtai_critical_exit(flags);
[15:23:06] <jepler> base/arch/x86/hal/hal_x86.c- rtai_request_tickdev(handler);
[15:23:07] <jepler> base/arch/x86/hal/hal_x86.c: rtai_critical_exit(flags);
[15:23:30] <jepler> so it looks like we have a version where this problem was not (yet) introduced...?
[15:23:31] <memleak> theres two of them?
[15:23:52] <jepler> you had two changes of rtai_critical_exit in your patch
[15:23:57] <jepler> I think those are the corresponding ones
[15:24:44] <memleak> oh nvm i thought in the rtai code for wheezy there were two in a row, i misread the message
[15:24:47] <jepler> hm that's all x86 though
[15:24:51] <jepler> two pastes
[15:25:25] <memleak> hal_x86.c is a file i made that merges 32 and 64 in one
[15:25:49] <memleak> i stopped doing that though just because it made merges more difficult
[15:29:48] <jepler> fair enough
[15:30:01] <jepler> that kind of reorg is not so great if you can't get an upstream to adopt it
[15:30:25] <memleak> i didnt care about upstream, still dont, never will. upstream is broken and always will be.
[15:32:00] <jepler> not much of an upstream then
[15:32:00] <memleak> i already did a major reorg with my new RTAI tree, much more complex than just file renaming
[15:32:05] <jepler> who are you merging with, then?
[15:32:49] <memleak> nobody, i might push the isolcpus fix though in with shabby's tree once its trimmed down
[15:33:14] <memleak> i probably should..
[15:33:56] <memleak> actually i just remembered, theres a linuxcnc branch in shabby's tree
[15:34:24] <memleak> it needs a new pull though from mine, ill do that once i get this going a bit better
[15:35:15] <jepler> argh standards
[15:35:53] <jepler> "0603" is a metric size equivalent to imperial "0201", while "0603" is an imperial size equivalent to metric "1608"
[15:37:52] <jepler> .. no wonder the smd caps I got were smaller than I expected
[15:39:51] <memleak> https://github.com/NTULINUX/RTAI/commit/d3bf33050b6065747748b65d866c9220b34e1f20
[15:39:59] <memleak> thats better right?
[15:44:51] <jepler> the commit message might be slightly misleading, since it also made additional new changes
[15:45:06] <jepler> if it were me, I might use rebase to combine the top two commits, then a forced push to rewrite history
[15:46:31] <memleak> the 32-bit change is documented in the commit
[15:46:39] <memleak> ^message
[15:47:28] <memleak> ok:
https://github.com/shabbyx/rtai/tree/linuxcnc
[15:47:51] <memleak> now i need to test this on a 32-bit system and fix whatever compiling errors from that
[15:47:56] <memleak> (if any)
[15:49:45] <memleak> jepler, to make it easier for 3.10 and 3.14 users (like me) to jump back and forth to earlier kernels whats a good way to detect version.h in configure.in file?
[15:51:40] <memleak> ah now i have to modify kernel patches and remove the free isolcpus function and rtai_sched_affinity
[15:51:48] <jepler> memleak: delete the line AC_CHECK_HEADERS([$KERNELDIR/include/linux/version.h],[],[AC_MSG_ERROR([version.h not found - Is the kernel headers package installed ?])])
[15:51:52] <jepler> ?
[15:52:12] <memleak> rofl.. ok :)
[15:52:23] <memleak> i was modifying the string but thats a lot easier
[15:53:06] <jepler> in 2007 I changed the VERSION_FILE so it could be the old include/linux/version.h or the new include/linux/utsrelease.h
[15:53:26] <jepler> but I never touched the check for version.h existing at all, which was apparently OK for only about 7 yeras or so
[15:53:29] <jepler> years
[15:53:45] <jepler> c17e070 Linux 2.6.34+ moved utsrelease.h
[15:54:13] <jepler> and
[15:54:14] <jepler> 9417bfd * Fix kernel version checking for 2.6.22.6-magma * Fix lyx detection for
[16:23:35] <memleak> now why am i getting spurious APIC interrupts with that new fix.
[16:24:29] <memleak> ah linuxcnc is now using the highest core all the time, as it should
[16:37:15] <jepler> hmmm
[16:37:30] <jepler> now I see why seb doesn't read the idrom and then decide what chip he's talking to
[17:05:45] <pcw_home> The chip name should always be there (the config name should be but isnt...)
[17:08:06] <micges> pcw_home: it's good time to introduce it along with idrom v4
[17:09:27] <micges> pcw_home: I mean more and more configs and it's hard to tell which is inside from --readhmid output
[17:09:28] <pcw_home> Yep along with a smarter stride system and connector hints
[17:11:16] <micges> what kind of hints?
[17:11:20] <pcw_home> I'll make a proto type 4 config next week some time
[17:11:22] <pcw_home> I intend to mainly steal module ID entries for other types of tags
[17:11:23] <pcw_home> (info tags, connector hints tags etc)
[17:12:21] <pcw_home> (0..23 = 7I33 family) for example
[17:14:03] <micges> make it for 5i25 + 7i77
[17:14:07] <pcw_home> pin range, daughterboard family
[17:14:08] <pcw_home> main structural change is strides are direct (and stride is 2^N per nibble)
[17:15:30] <pcw_home> currently there are only 2 sets of strides available which makes some configs impossible now
[17:17:22] <micges> yeah
[17:20:43] <pcw_home> I'm thinking of changing the module rev system also so theres a major and minor nibble
[17:20:45] <pcw_home> (that would have avoided the encoder V4 issues)
[17:23:20] <micges> only incopatible changes change major number right?
[17:48:38] <pcw_home> Yeah firmware changes that require driver changes or bug fixes (major) as opposed to
[17:48:40] <pcw_home> enhancements that are backward compatible (minor)
[17:55:32] <micges> 'nite
[19:26:37] <jepler> pcw_home: the identity infrastructure dates from when all cards had volatile firmware, so the only way to kknow what card it is, is via pci metadata...
[20:31:44] <pcw_home> Right, or implicit from the driver (7I43)
[22:24:51] <cmorley> pcw_home: I looked at updating my 7i77 and 7i76 sserial. The docs mention that the host FPGA firmware muat be
[22:24:51] <cmorley> sserial version >33. Mine say it's version 33. What do I do then? Thanks
[23:21:34] <pcw_home> update your 5I25/6I25 with the appropriate bitfile from 5i25.zip with mesaflash
[23:31:21] <memleak> hey jepler i just wanted to thank you again for helping me get new kernels working with linuxcnc
