Back
[00:01:28] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
[00:07:30] -!- xeedlog01 has quit [Remote host closed the connection]
[00:08:55] -!- FreezingCold has quit [Quit: Out]
[00:12:58] -!- xeedlog01 has quit [Remote host closed the connection]
[00:18:12] -!- anth0ny_ has quit [Quit: anth0ny_]
[00:21:14] -!- xeedlog01 has quit [Remote host closed the connection]
[00:25:40] -!- xeedlog01 has quit [Remote host closed the connection]
[00:25:40] -!- xeedlog02 has quit [Remote host closed the connection]
[00:27:54] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[00:28:42] -!- xeedlog01 has quit [Remote host closed the connection]
[00:28:42] -!- xeedlog02 has quit [Remote host closed the connection]
[00:36:15] -!- ries has quit [Quit: ries]
[00:44:13] -!- xeedlog02 has quit [Remote host closed the connection]
[00:44:14] -!- xeedlog01 has quit [Remote host closed the connection]
[00:46:13] -!- xeedlog01 has quit [Remote host closed the connection]
[01:02:40] -!- brianmorel99 has quit [Ping timeout: 255 seconds]
[01:23:50] -!- tinkerer has quit [Ping timeout: 260 seconds]
[01:28:32] -!- Benjamin23 has quit [Ping timeout: 245 seconds]
[01:28:58] <pcw_home> the script is in here, it uses setsserial which is in linuxcnc 2.6 or later
[01:29:00] <pcw_home> http://www.mesanet.com/software/parallel/sserial.zip
[02:26:36] <pcw_home> Oh and the remote firmware version is a HAL parameter
[02:27:23] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[02:42:28] <micges> pcw_home: hi
[02:43:34] <micges> eta of 7i92 and 7i54?
[02:45:56] <pcw_home> kits being put together now so maybe a couple weeks for 7I54 and a month for 7I92
[02:46:50] <micges> good
[02:49:04] <jepler> what's i54?
[02:50:34] <micges> 6x small 3A H bridge
[02:50:54] <micges> iirc 30V
[02:51:28] <micges> jepler: btw great work with spi
[02:55:20] <jepler> micges: it was easy with hm2_eth to study, and the queued I/O stuff helped
[02:55:31] <jepler> micges: still, it's not giving good RT performance on my box so there's more work ahead
[03:02:42] <micges> glad it helps
[03:06:07] <jepler> I guess I'll just put some art in the blank area
http://emergent.unpythonic.net/files/sandbox/art.png
[03:07:19] <micges> haha
[03:12:11] <jepler> wow these are art
http://boldport.blogspot.com/2014/02/so-you-want-to-manufacture-your-printed.html
[03:19:06] -!- FreezingCold has quit [Ping timeout: 260 seconds]
[03:22:32] <CaptHindsight> jepler: we getting some odd latency test results with isolcpus with 3.14 64b RTAI
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2#Latency_test_results_for_isolcpus
[03:23:54] <CaptHindsight> we also need to find a utility that accurately tells us what core each process is actually running on
[03:26:22] -!- micges has quit [Quit: Leaving]
[03:27:47] <jepler> CaptHindsight: for userspace processes, cpuset can display the mark of CPUs where the process is allowed to run.
[03:30:03] <jepler> one of the fieids in /proc/<PID>/stat is "which CPU the task is scheduled on"
[03:31:14] <jepler> field number 39 by my count
[03:32:46] <jepler> (1-based)
[03:33:15] <jepler> er taskset, not cpuset
[03:34:00] <jepler> and setting process affinity via taskset and then retrieving it via /proc/PID/stat matches
[03:35:26] <jepler> and of course the default affinity mask matches isolcpus=
[03:36:31] <jepler> and running a CPU-bound program when RT is (de)tuned to use 50% CPU showed 50% lower throughput of userspace program when bound to the same CPU that the rtai realtime thread was bound to
[03:36:49] <jepler> I'm pretty sure the CPU numbers in taskset, /proc, and rtai really do agree
[03:38:00] <jepler> and even in your new table, it looks like the advice "isolate both CPUs in a pair in bulldozer+" correctly predicts the latency figures you got
[03:38:29] <jepler> you must have misplaced a digit in quoting some of those numbers, though
[03:38:53] <jepler> > 172,081,81
[03:40:22] <CaptHindsight> let me fix those
[03:42:31] <CaptHindsight> updated
[03:43:09] -!- AR_ has quit [Ping timeout: 240 seconds]
[03:44:12] <CaptHindsight> memleak also tested without the isolcpus parameter and every few reboots latency would be as low as if isolcpus was used and set to =2,3
[03:45:14] <CaptHindsight> so the proposed master branch might randomly choose cores for real time if it's not forced
[03:45:27] <CaptHindsight> by isolcpus=
[03:46:12] <jepler> no it doesn't
[03:46:13] <jepler> read the code
[03:46:23] <jepler> the code does not look at isolcpus= in selecting what CPU to bind to
[03:46:29] <jepler> the code binds to the highest numbered CPU
[03:46:53] <memleak> what section of the code?
[03:47:02] <memleak> file, line area?
[03:47:22] <jepler> rtai_rtapi.c in the linuxcnc source tree
[03:47:26] <memleak> ok
[03:47:28] <jepler> 187 /* on SMP machines, we want to put RT code on the last CPU */
[03:47:28] <jepler> 188 n = NR_CPUS-1;
[03:47:28] <jepler> 189 while ( ! cpu_online(n) ) {
[03:47:28] <jepler> 190 n--;
[03:47:28] <jepler> 191 }
[03:47:30] <jepler> 192 rtapi_data->rt_cpu = n;
[03:47:49] -!- sylphiae has quit [Ping timeout: 272 seconds]
[03:47:55] <jepler> also while linuxcnc is running, if you have working *rtai* /proc, you can read there the CPU that the realtime task actually bound to
[03:48:06] <jepler> it matches what the algorithm's comment says: last (highest numbered) CPU
[03:48:17] <memleak> ok
[03:48:23] <jepler> (a cpu is "online" even if it is in isolcpus, at least in kernels I tested)
[03:49:42] <jepler> (mostly 3.2 preempt-rt and 3.4 rtai in this go-around)
[03:50:24] <jepler> /proc/interrupts is interesting too, it'll tell you how often each IRQ has been delivered to each CPU
[03:51:14] <jepler> goodnight
[03:51:50] <CaptHindsight> so does setting isolcpus=3 keeps other (non real time) threads from using core 3?
[03:52:03] <CaptHindsight> tomorrow
[03:52:56] <jepler> boot without isolcpus, and then with isolcpus=3, and look at the cpu mask of your general linux processes
[03:52:59] <jepler> they'll exclude CPU 3
[03:53:12] <CaptHindsight> latency will change
[03:53:14] <jepler> some processes are still allowed to be scheduled on CPU 3 though, because linux wants to
[03:53:34] <CaptHindsight> 3 out of 4 tries it will be poor and then it will be really low
[03:53:34] <jepler> e.g., taskset -pc $$ or taskset -pc 1
[03:54:07] <CaptHindsight> thats another odd behavior
[03:55:24] <CaptHindsight> g'nite
[04:06:12] -!- Khetzal has quit [Ping timeout: 250 seconds]
[04:16:22] -!- Khetzal [Khetzal!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[04:37:49] -!- martin___ has quit [Remote host closed the connection]
[04:43:48] -!- martin___ has quit [Ping timeout: 260 seconds]
[05:01:46] -!- Fox_Muldr has quit [Ping timeout: 250 seconds]
[05:06:59] -!- stephan48 has quit [Ping timeout: 272 seconds]
[05:12:47] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[05:15:32] -!- FinboySlick has quit [Quit: Leaving.]
[05:21:28] -!- kwallace2 [kwallace2!~kwallace@smb-89.sonnet.com] has parted #linuxcnc-devel
[05:45:51] -!- likevinyl has quit [Quit: likevinyl]
[05:57:03] -!- sirdancealot has quit [Ping timeout: 240 seconds]
[05:59:52] -!- anth0ny_ has quit [Quit: anth0ny_]
[06:03:23] -!- kwallace4 has quit [Read error: Connection reset by peer]
[06:04:28] -!- kwallace [kwallace!~kwallace@smb-248.sonnet.com] has joined #linuxcnc-devel
[06:57:43] -!- koss has quit [Ping timeout: 255 seconds]
[07:40:22] -!- zeeshan has quit [Ping timeout: 250 seconds]
[07:43:56] -!- karavanjo_ has quit [Ping timeout: 260 seconds]
[07:47:38] -!- karavanjo has quit [Read error: Connection reset by peer]
[08:27:25] -!- eeriegeek has quit [Quit: Leaving.]
[08:36:07] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[08:36:07] -!- anarchos has quit [Ping timeout: 245 seconds]
[08:48:57] -!- karavanjo_ has quit [Ping timeout: 245 seconds]
[09:02:29] -!- almccon has quit [Read error: Connection reset by peer]
[09:06:23] -!- almccon_ has quit [Ping timeout: 272 seconds]
[09:19:19] -!- travalga has quit [Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140715214327]]
[09:22:41] -!- b_b has quit [Changing host]
[10:39:35] -!- martin___ has quit [Remote host closed the connection]
[11:10:30] -!- ries has quit [Ping timeout: 255 seconds]
[11:16:31] -!- marti____ has quit [Remote host closed the connection]
[11:19:11] -!- mhaberler has quit [Quit: mhaberler]
[11:23:46] -!- MrSunshine has quit [Quit: Leaving]
[11:25:12] -!- syyl_ has quit [Ping timeout: 245 seconds]
[11:55:00] -!- FreezingCold has quit [Ping timeout: 260 seconds]
[11:55:16] dave is now known as Guest7452
[13:04:56] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[13:24:45] -!- FreezingCold has quit [Ping timeout: 246 seconds]
[13:33:24] -!- memleak [memleak!~memleak@unaffiliated/memfrob] has parted #linuxcnc-devel
[13:33:43] -!- memleak [memleak!~memleak@unaffiliated/memfrob] has joined #linuxcnc-devel
[14:05:13] -!- kwallace1 [kwallace1!~kwallace@smb-248.sonnet.com] has joined #linuxcnc-devel
[14:05:45] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[14:19:02] -!- amiri has quit [Ping timeout: 245 seconds]
[14:32:32] <memleak> hi, does linuxcnc use rtai_mq (posix like message queues in RTAI)
[14:39:50] <jepler> memleak: no file in linuxcnc includes rtai_mq.h
[14:41:53] <memleak> i fixed the scheduler!
[14:42:06] <memleak> it was in-kernel RTAI code
[14:42:32] <memleak> rtai_sched_affinity was hosed
[14:43:22] <memleak> now im not getting realtime delays outside of what appears to be a low-latency latency-test
[14:43:30] <memleak> and no system hick ups either
[14:43:36] <memleak> this is perfect!
[14:43:49] <memleak> no need for ancient checkouts of RTAI anymore!
[14:44:15] <memleak> also the "last interval" column actually updates as fast as it used to
[14:44:50] <memleak> rtapi threads now close a lot quicker too, without delays, no system freezes... im stunned.
[14:45:26] <memleak> now to update the rtai github tree and clean the fix up
[14:45:35] <jepler> I'll be interested to see what you found
[14:46:00] <memleak> :DDDDDD
[14:46:57] -!- syyl has quit [Ping timeout: 245 seconds]
[15:03:53] <memleak> i can compile linuxcnc with 4 cores again too...
[15:12:22] <jepler> it looks like the mating distance of these connectors is close enough to .25in that a commonly-available standoff should do nicely
[15:12:27] <jepler> that's happy-making
[15:13:20] <jepler> bbl
[15:13:50] -!- bedah has quit [Remote host closed the connection]
[15:32:04] <memleak> thats odd i cant reproduce it now :/
[15:39:22] -!- skorasaurus has quit [Ping timeout: 240 seconds]
[15:43:03] <memleak> oh thats why, heh i installed a wrong RTAI to /usr/realtime
[15:45:48] -!- FreezingCold has quit [Ping timeout: 246 seconds]
[15:47:33] <Tom_itx> jepler, if they're metric it'll bend the pins
[15:52:59] -!- Tecan has quit [Ping timeout: 272 seconds]
[15:53:56] -!- ktchk [ktchk!~eddie6929@n219078190148.netvigator.com] has joined #linuxcnc-devel
[15:56:37] -!- JLuc69_ has quit [Quit: Quitte]
[16:08:05] <memleak> it worked for a second...
[16:08:23] <memleak> im really getting aggrivated im takin a break from this crap
[16:14:54] -!- anth0ny_ has quit [Client Quit]
[16:26:24] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[16:26:35] <jepler> Tom_itx: .25in is just a little more than the "correct" mating distance (5%)
[16:26:49] <jepler> (6mm)
[16:34:23] <Tom_itx> i just mentioned it because i've had board regrets before
[16:39:23] -!- b_b has quit [Changing host]
[16:40:41] -!- bedah has quit [Ping timeout: 260 seconds]
[16:41:20] <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
[16:42:07] <jepler> new "under" board will have 4 mounting holes to match the main board so it doesn't misalign like that
[16:44:31] <Tom_itx> if you're gonna redo it and add mounts i'd change to the correct plug too
[16:44:33] -!- ktchk [ktchk!~eddie6929@n219078190148.netvigator.com] has parted #linuxcnc-devel
[16:45:15] <jepler> if you mean the way it's connected to the board in the background, that's unrelated jank
[16:45:39] <Tom_itx> no
[16:45:44] <Tom_itx> the underside plug
[16:45:50] <Tom_itx> pin spacing
[16:46:27] <jepler> the female receptacle and the pin header are both 2mm pitch
[16:46:36] <Tom_itx> ahh ok
[16:46:51] <Tom_itx> i thought you were trying to force a .1 plug
[16:47:02] <jepler> no, the slant is just because that's how gravity made it sit
[16:47:07] <Tom_itx> right
[16:47:23] <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
[16:47:50] <Tom_itx> you'd be surprised what some will try :D
[16:51:23] <jepler> pcw_home: just found the fedex door tag from that board you shipped me.. so I'll have it in my hands monday.
[16:51:29] -!- anth0ny_ has quit [Quit: anth0ny_]
[16:57:45] -!- mhaberler has quit [Quit: mhaberler]
[17:05:41] <pcw_home> I guess you can't check it yet with your 2mm connector issues :-(
[17:07:20] <jepler> pcw_home: nope, more waiting
[17:07:22] <KGB-linuxcnc> 03Jeff Epler 05master 4be377e 06linuxcnc Merge branch 'jepler/proposed-master' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4be377e
[17:08:28] <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
[17:08:28] <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
[17:08:47] <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
[17:09:27] <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
[17:09:27] <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
[17:22:17] -!- shurshur has quit [Ping timeout: 272 seconds]
[17:28:33] -!- anth0ny_ has quit [Client Quit]
[17:28:53] -!- shurshur has quit [Remote host closed the connection]
[17:35:03] -!- balestrino has quit [Ping timeout: 240 seconds]
[17:38:43] -!- tjb1 has quit [Read error: Connection reset by peer]
[17:41:30] -!- patrickarlt has quit [Remote host closed the connection]
[17:52:28] -!- micges [micges!~captain_p@aehw238.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[17:54:14] -!- anth0ny_ has quit [Quit: anth0ny_]
[18:00:40] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[18:08:24] <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>
[18:11:19] <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>
[18:11:29] <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>
[18:11:30] <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>
[18:11:44] <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>
[18:12:07] <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>
[18:13:00] -!- i_tarzan has quit [Ping timeout: 260 seconds]
[18:14:28] <jepler> oh foo
[18:14:49] <jepler> .. I'll fix it shortly
[18:15:43] <jepler> hm I guess it was confused by a forced push I did?
[18:20:01] <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>
[18:25:49] <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>
[18:27:12] <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>
[18:28:59] -!- james628 has quit [Quit: Page closed]
[18:29:51] <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>
[18:34:36] -!- ries has quit [Ping timeout: 250 seconds]
[18:37:43] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:42:12] <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>
[18:43:30] <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>
[18:43:32] <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>
[18:44:14] <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>
[18:45:41] <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>
[18:46:01] <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>
[18:48:09] <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>
[18:48:10] <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>
[18:53:05] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[19:03:32] -!- patrickarlt has quit [Remote host closed the connection]
[19:06:06] -!- ybon has quit [Quit: WeeChat 0.4.2]
[19:07:52] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[19:08:51] -!- patrickarlt has quit [Ping timeout: 255 seconds]
[19:19:52] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[19:21:55] <memleak> ok scheduler is fixed again
[19:24:21] <memleak> https://github.com/NTULINUX/RTAI/commit/e53f8388491a99acf2e99bcc3522daa18767feb4
[19:24:29] <memleak> ah and my timer is showing up properly in dmesg!
[19:24:38] -!- onyedikilo_ has quit [Quit: Page closed]
[19:28:11] <memleak> i dont think i need 8259 code in there.. at least not in hal_64.c
[19:32:20] -!- anarchos has quit [Ping timeout: 250 seconds]
[19:35:16] -!- sylphiae has quit [Ping timeout: 250 seconds]
[19:37:04] <jepler> which part of that change was the real aha for you? and how much is the performance improved?
[19:38:03] <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
[19:38:11] <memleak> and the performance is night and day
[19:38:42] <memleak> maybe just strip out the 8259 code this time... that code is so sensitive..
[19:40:10] <memleak> extremely sensitive to breakage.
[19:40:52] -!- micges1 [micges1!~captain_p@aebh230.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:42:08] -!- jasen_ has quit [Quit: Page closed]
[19:43:57] -!- micges has quit [Ping timeout: 245 seconds]
[19:44:05] <memleak> ok that worked.. now little by little im going to revert portions of that patch
[19:45:19] <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?
[19:51:37] <memleak> looks to be the position of critical_exit functions
[19:51:43] <memleak> not 100% sure yet
[19:52:09] <jepler> memleak: you can "git revert --no-commit" the commit you want to play with
[19:52:18] <jepler> memleak: commit a smaller part of it, then "git stash" the rest
[19:52:51] <jepler> (that's if you want to think about partially reverting the commit)
[19:52:56] <memleak> would git stash hide it from github?
[19:53:05] <jepler> until you "git push" nothing on github changes
[19:53:11] <memleak> well obviously
[19:53:38] <memleak> git revert though shows up as "revert commit blah blah blah"
[19:53:48] <jepler> git revert --no-commit doesn't create a commit
[19:53:54] <memleak> oh...
[19:54:02] <memleak> awesome i hate those!
[19:55:26] <jepler> more suggestions from the internet:
http://stackoverflow.com/questions/4795600/reverting-part-of-a-commit-with-git
[19:56:12] <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
[19:56:38] <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)
[19:56:52] <jepler> (revert with "git reset --hard")
[19:58:00] <memleak> yup its the position of rtai_critical_exit
[19:58:05] <jepler> (I used "revert" in its non-technical sense)
[19:58:48] <memleak> thats so odd...
[19:58:58] <memleak> figured it'd be more than just one line of code..
[20:01:42] <jepler> which version did this problem get added in? Does it affect back to the one we're shipping with debian wheezy?
[20:02:16] <memleak> depends which checkout of RTAI
[20:03:42] <memleak> im using gentoo so i have no idea
[20:03:48] <jepler> base/arch/x86/hal/hal_x86.c- rt_release_irq(RTAI_APIC_TIMER_IPI);
[20:03:48] <jepler> base/arch/x86/hal/hal_x86.c: rtai_critical_exit(flags);
[20:04:18] <jepler> base/arch/x86/hal/hal_x86.c- rtai_request_tickdev(handler);
[20:04:18] <jepler> base/arch/x86/hal/hal_x86.c: rtai_critical_exit(flags);
[20:04:42] <jepler> so it looks like we have a version where this problem was not (yet) introduced...?
[20:04:43] <memleak> theres two of them?
[20:05:04] <jepler> you had two changes of rtai_critical_exit in your patch
[20:05:09] <jepler> I think those are the corresponding ones
[20:05:56] <memleak> oh nvm i thought in the rtai code for wheezy there were two in a row, i misread the message
[20:05:59] <jepler> hm that's all x86 though
[20:06:03] <jepler> two pastes
[20:06:37] <memleak> hal_x86.c is a file i made that merges 32 and 64 in one
[20:07:01] <memleak> i stopped doing that though just because it made merges more difficult
[20:11:00] <jepler> fair enough
[20:11:13] <jepler> that kind of reorg is not so great if you can't get an upstream to adopt it
[20:11:37] <memleak> i didnt care about upstream, still dont, never will. upstream is broken and always will be.
[20:13:12] <jepler> not much of an upstream then
[20:13:12] <memleak> i already did a major reorg with my new RTAI tree, much more complex than just file renaming
[20:13:17] <jepler> who are you merging with, then?
[20:14:00] <memleak> nobody, i might push the isolcpus fix though in with shabby's tree once its trimmed down
[20:14:25] <memleak> i probably should..
[20:15:08] <memleak> actually i just remembered, theres a linuxcnc branch in shabby's tree
[20:15:36] <memleak> it needs a new pull though from mine, ill do that once i get this going a bit better
[20:16:27] <jepler> argh standards
[20:17:05] <jepler> "0603" is a metric size equivalent to imperial "0201", while "0603" is an imperial size equivalent to metric "1608"
[20:19:04] <jepler> .. no wonder the smd caps I got were smaller than I expected
[20:21:03] <memleak> https://github.com/NTULINUX/RTAI/commit/d3bf33050b6065747748b65d866c9220b34e1f20
[20:21:10] <memleak> thats better right?
[20:26:03] <jepler> the commit message might be slightly misleading, since it also made additional new changes
[20:26:18] <jepler> if it were me, I might use rebase to combine the top two commits, then a forced push to rewrite history
[20:27:40] -!- dnaleromj has quit []
[20:27:42] <memleak> the 32-bit change is documented in the commit
[20:27:51] <memleak> ^message
[20:28:40] <memleak> ok:
https://github.com/shabbyx/rtai/tree/linuxcnc
[20:29:03] <memleak> now i need to test this on a 32-bit system and fix whatever compiling errors from that
[20:29:08] <memleak> (if any)
[20:30:56] <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?
[20:32:51] <memleak> ah now i have to modify kernel patches and remove the free isolcpus function and rtai_sched_affinity
[20:33:00] <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 ?])])
[20:33:03] <jepler> ?
[20:33:24] <memleak> rofl.. ok :)
[20:33:35] <memleak> i was modifying the string but thats a lot easier
[20:34:18] <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
[20:34:38] <jepler> but I never touched the check for version.h existing at all, which was apparently OK for only about 7 yeras or so
[20:34:41] <jepler> years
[20:34:57] <jepler> c17e070 Linux 2.6.34+ moved utsrelease.h
[20:35:25] <jepler> and
[20:35:26] <jepler> 9417bfd * Fix kernel version checking for 2.6.22.6-magma * Fix lyx detection for
[20:43:34] -!- kfoltman has quit [Remote host closed the connection]
[20:45:41] -!- Deejay has quit [Quit: bye]
[21:04:47] <memleak> now why am i getting spurious APIC interrupts with that new fix.
[21:05:41] <memleak> ah linuxcnc is now using the highest core all the time, as it should
[21:10:17] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[21:14:50] -!- patrickarlt has quit [Remote host closed the connection]
[21:18:27] <jepler> hmmm
[21:18:42] <jepler> now I see why seb doesn't read the idrom and then decide what chip he's talking to
[21:20:14] -!- patrickarlt has quit [Ping timeout: 255 seconds]
[21:38:28] -!- MrSunshine has quit [Remote host closed the connection]
[21:46:57] <pcw_home> The chip name should always be there (the config name should be but isnt...)
[21:48:15] micges1 is now known as micges
[21:49:17] <micges> pcw_home: it's good time to introduce it along with idrom v4
[21:50:39] <micges> pcw_home: I mean more and more configs and it's hard to tell which is inside from --readhmid output
[21:50:40] <pcw_home> Yep along with a smarter stride system and connector hints
[21:52:28] <micges> what kind of hints?
[21:52:32] <pcw_home> I'll make a proto type 4 config next week some time
[21:52:34] <pcw_home> I intend to mainly steal module ID entries for other types of tags
[21:52:35] <pcw_home> (info tags, connector hints tags etc)
[21:53:33] <pcw_home> (0..23 = 7I33 family) for example
[21:55:14] <micges> make it for 5i25 + 7i77
[21:55:19] <pcw_home> pin range, daughterboard family
[21:55:20] <pcw_home> main structural change is strides are direct (and stride is 2^N per nibble)
[21:56:32] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[21:56:41] <pcw_home> currently there are only 2 sets of strides available which makes some configs impossible now
[21:58:34] <micges> yeah
[22:01:55] <pcw_home> I'm thinking of changing the module rev system also so theres a major and minor nibble
[22:01:57] <pcw_home> (that would have avoided the encoder V4 issues)
[22:04:32] <micges> only incopatible changes change major number right?
[22:05:38] -!- theorbtwo has quit [Ping timeout: 250 seconds]
[22:06:18] -!- bedah2 has quit [Quit: Ex-Chat]
[22:06:34] -!- tjb1 has quit [Read error: Connection reset by peer]
[22:20:10] -!- mhaberler has quit [Quit: mhaberler]
[22:25:20] -!- tjb1 has quit [Read error: Connection reset by peer]
[22:27:56] -!- AR_ has quit [Read error: Connection reset by peer]
[22:29:50] <pcw_home> Yeah firmware changes that require driver changes or bug fixes (major) as opposed to
[22:29:51] <pcw_home> enhancements that are backward compatible (minor)
[22:34:22] -!- patrickarlt has quit [Remote host closed the connection]
[22:36:44] <micges> 'nite
[22:36:49] -!- micges has quit [Quit: Leaving]
[22:39:27] -!- patrickarlt has quit [Ping timeout: 255 seconds]
[23:13:37] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[23:18:53] -!- anth0ny_ has quit [Quit: anth0ny_]
[23:29:22] -!- somenewguy has quit [Quit: WeeChat 0.4.3]
[23:43:11] -!- anth0ny_ has quit [Quit: anth0ny_]
