Back
[10:12:36] <jepler> huh, ubuntu on -rt kernels:
[10:12:39] <jepler> >>> The -preempt and -rt kernels are no longer being developed due to lack of support. Focus has instead turned to the -lowlatency and -realtime kernels, particularly for the the release of Ubuntu 11.04 Natty Narwhal. The long-term goal is to have -lowlatency in the official Ubuntu repositories, while maintaining -realtime in a dedicated PPA.
[10:13:00] <jepler> what's a -realtime kernel, as compared to a -rt kernel?
[10:13:26] <jepler> > From a technical point of view, -rt and -realtime are the same kernel. They are both based on the PREEMPT_RT patchset, although the version may be different
[10:14:03] <jepler> > On the other hand, the -realtime kernel is a PREEMPT_RT patched kernel based on the vanilla source tree (not the Ubuntu source).
[11:10:41] <seb_kuzminsky> jepler: i'm super excited for the posix branch
[11:11:12] <seb_kuzminsky> i'm going to install with cradek's wheezy live-cd on a spare partition on my bridgeport, then i'll try out your branch on it
[11:11:17] <seb_kuzminsky> it's got a 5i22
[11:12:28] <seb_kuzminsky> this makes me excited to get 2.6 out, so we can start getting this new feature out for 2.7 :-)
[11:14:02] <cradek_> yes I sure agree with that
[11:14:24] <cradek_> unfortunately I still haven't managed to get the lapic to survive the install
[11:14:28] <cradek_> I'd like to figure that out
[11:15:40] <seb_kuzminsky> i'd like to get the same kernel running on precise, then imma call it good
[11:17:07] <cradek> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/581796
[11:17:11] <cradek> well it ain't me
[11:30:00] <seb_kuzminsky> then it ain't your job to fix (unless you choose to nobly add work to your plate), and we should release as is
[11:30:15] <cradek> well now it's my job to hack around
[11:30:38] <cradek> seems like it's been reported many times over 4+ years to ubuntu but never kicked upstream
[11:36:09] <cradek> seb_kuzminsky: can you somehow make a ~pre4 wheezy build go to the l.o repo? I'm working on getting the sources right after install, and for the release I don't want buildbot in there anymore
[11:40:47] <seb_kuzminsky> yes, i'll do that, it'll be a couple hours at least
[11:42:20] <seb_kuzminsky> i wish linuxcnc-build_ 's irc presence was smart enough to survive a netsplit
[11:44:27] <Tom_itx> i swear i saw 'release' in this page somewhere...
[11:45:09] <seb_kuzminsky> heh
[11:45:19] <seb_kuzminsky> the time is nigh
[11:45:40] <seb_kuzminsky> as we say at my day job: we've never been closer
[11:46:04] <cradek> seb_kuzminsky: thank you! maybe I can roll a final test image still this weekend then
[11:47:39] <jepler> seb_kuzminsky: if you're excited enough, I can just merge it to 2.6.
[11:48:43] <jepler> (I'm pretty confident that's a joke)
[11:59:42] <cradek> sigh, no, Alt-F4 in qemu in the middle of an install doesn't give you that other console...
[12:03:12] <jepler> oops, ow
[12:04:02] <cradek> at least while working on the preseed, I can fetch it over http and not rebuild the image (1 hour) each time
[12:20:45] <linuxcnc-build> build #2199 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2199
[12:24:09] <linuxcnc-build> build #2201 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2201
[12:34:31] <jepler> seb_kuzminsky: OK for 2.6? They make linuxcnc build and pass tests on an arm chromebook running debian 7 in crouton.
http://emergent.unpythonic.net/files/sandbox/arm-patches.mbox.txt
[12:52:43] <cradek> yay, lapic
[12:52:53] <jepler> as for that failure:
[12:52:54] <jepler> emcTaskPlanCommand(o<sub> endsub) called. (line_number=7)
[12:52:54] <jepler> emc/task/emctask.cc 389: interp_error: cannot reopen file (null) - removed or renamed? (No such file or directory)
[12:52:57] <jepler> cannot reopen file (null) - removed or renamed? (No such file or directory)
[12:53:10] <jepler> I think I've seen this another time recently from the buildbot. I haven't looked into it
[12:55:23] <jepler> where the message has "(null)" the enclosing code doesn't seem to be passing in the actual file that was opened
[12:55:32] <jepler> settings->file_pointer = fopen(previous_frame->filename, "r");
[12:55:35] <jepler> if (settings->file_pointer == NULL) {
[12:55:38] <jepler> ERS(NCE_CANNOT_REOPEN_FILE,
[12:55:40] <jepler> settings->sub_context[settings->call_level].filename,
[12:55:43] <jepler> strerror(errno));
[12:55:46] <jepler> }
[12:56:08] <jepler> so we don't even know what file couldn't be open
[12:57:08] <jepler> .. on my system, fopen(NULL, "r") sets errno to EFAULT
[12:59:01] <jepler> ugh, the commit that changed the fopen argument has this terrible commit message:
[12:59:04] <jepler> >>>
[12:59:05] <jepler> <<<
[12:59:07] <jepler> wip - looks good in mdi & auto
[12:59:09] <jepler> Conflicts:
[12:59:12] <jepler> src/emc/rs274ngc/rs274ngc_pre.cc
[13:36:38] <skunkworks> jepler: neat - I thought you where getting <20us latencys with the rt_preept.. that is as good as rtai on most machines..
[13:37:57] <skunkworks> I can test the 5i25 - also - I can test the 7i80..
[13:43:45] <jepler> skunkworks: sometihng like 10-12us, though I'm not running X at the console so it may not really count
[13:45:45] <jepler> though I meant to say that rt-preempt is *not* good enough for software step generation
[13:59:14] <skunkworks> jepler: ok. why, if the latency is decent, would it not work for software step gen?
[14:00:29] <jepler> skunkworks: maybe I've forgotten the math, but it seems like that doesn't give you much step rate
[14:01:46] <skunkworks> 10 -12us is as good or better than rtai on a lot of systems...
[14:02:24] <jepler> hm ok
[14:02:31] <skunkworks> the default base period in most configs is 50us
[14:03:23] <skunkworks> that would give you 20khz without doublestep
[14:04:28] <skunkworks> at 10 - 12us - you might be able to run a 25us base thread...
[14:04:50] <skunkworks> that would be 40khz without doublestep
[14:07:29] <jepler> hm ok then
[14:07:42] <jepler> I wonder what the latency would be if I was running X and stressing it, though
[14:08:09] <archivist> I get just under 16k latency on a recent old box
[14:08:11] <skunkworks> when I was playing with rt_preempt with the 7i80 and ubc - the best I got was around 80us - that was runing the normal latency test
[14:08:31] <skunkworks> (base and servo thread)
[14:08:57] <skunkworks> or maybe I wasn't running a base thread.. I really don't remember..
[14:09:11] <jepler> originally I saw 80ms on a 1ms servo thread when I ran without a base thread
[14:11:31] <jepler> that's "fixed" by opening a special file and writing "0" to it
[14:32:52] <KGB-linuxcnc> 03Jeff Epler 052.6 11f48ef 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc interp: print correct filename in message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11f48ef
[14:32:52] <KGB-linuxcnc> 03Jeff Epler 052.6 b2b1954 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh 10src/emc/rs274ngc/rs274ngc_pre.cc interp: need to initialize context_struct * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b2b1954
[15:10:14] <seb_kuzminsky> welp, found the breaker
[15:10:52] <seb_kuzminsky> jepler: did you say (before i disconnected) that the build failure we just got (
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2199/steps/runtests/logs/stdio) was fixed with the commits you just pushed?
[15:11:18] <seb_kuzminsky> if so maybe i should make a 2.6.0~pre5 instead of trying to build ~pre4 again
[15:20:00] <jepler> seb_kuzminsky: I believe it is
[15:28:50] <seb_kuzminsky> ugh, 2.5 doesn't merge into 2.6 because of conflicts in the french docs
[15:32:22] <jepler> to resolve that, I'd have to understand the difference between _..._ and '...', not french
[15:36:22] <JT-Shop> '...' is italics and _..._ is italic too
[15:37:17] <JT-Shop> in AsciiDoc
[15:37:34] <jepler> seb_kuzminsky: I can do the merge if you like
[15:44:37] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision=v2.6.0-pre4 0000.checkin
[15:44:43] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[15:44:55] <seb_kuzminsky> jepler: thanks, i'd appreciate that. i'm running around doing house projects today
[15:45:34] <seb_kuzminsky> has anyone done any testing beyond runtests on the new 3.4-9-rtai-686-pae kernel? i haven't
[15:47:22] <KGB-linuxcnc> 03Jeff Epler 052.6 208025b 06linuxcnc 10docs/html/gcode_fr.html 10docs/src/config/ini_config_fr.txt 10docs/src/gcode/gcode_fr.txt Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=208025b
[15:48:14] <jepler> seb_kuzminsky: not I. I wanted to use it when my 5i20 card was misbehaving, but I had an amd64 install so it didn't help
[15:48:40] <jepler> (weird problem. apparently the id eeprom had spontaneously deprogrammed itself. fixed by running the DOS eeprom programmer)
[18:00:47] <jepler> I wonder why debian doesn't package -rt kernels for arm
[18:02:05] <jepler> .. maybe pre-built arm kernels only work on a few devices anyway
[18:21:12] <dgarr> seb_kuzminsky: i
[18:22:33] <dgarr> i have loaded the 3.4.9-rtai on wheezy and get an oops at realtime start on a machine (amd sempron) that has run lucid-rtai for years
[18:22:36] <dgarr> http://www.panix.com/~dgarrett/stuff/3.4-9-rtai.txt
[18:22:58] <dgarr> maybe there is a clue in the syslog report
[18:23:42] <skunkworks> jepler: is there a 101 on installing the -rt kernel?
[18:29:39] <seb_kuzminsky> thanks for the report, dgarr
[18:29:44] <seb_kuzminsky> i'll take a look at it
[18:31:19] <dgarr> skunkworks: on wheezy, there is a -rt image available so it is easy with synaptic (i think) linux-image-3.2.0-4-rt-686-pae
[18:36:28] <CaptHindsight> anyone know if you still have to set the stepgen a few % higher for each axis than the trajectory section of the .ini?
[18:50:32] <micges-dev> CaptHindsight: yes, you still have to
[18:50:57] <CaptHindsight> micges-dev: thanks, did it anyway :)
[18:52:58] <micges-dev> heh ok
[19:01:22] <jepler> skunkworks: yes, on debian 7 install the realtime kernel image, linux-image-3.2.0-4-rt-686-pae or -amd64. then build linuxcnc with --enable-realtime=uspace, make and (this is new) sudo make setuid
[19:02:08] <skunkworks> micges-dev: how hard is it to make the mesa ethernet work with uspace?
[19:04:52] <micges-dev> I think it will just works
[19:05:38] <skunkworks> oh
[19:06:01] <skunkworks> jepler: could you bring the hm2-ethernet into your branch?
[19:06:05] <jepler> I hope it will. I haven't tried cherry-picking the commits onto my branch, though. don't have hardware to test with anyway.
[19:07:17] <jepler> skunkworks: if you mean origin/ubc3-7i80 that's not easy because just doing a merge of that branch would bring in a pile of undesired stuff
[19:07:33] <dgarr> jepler: is new uspace work required for hal_ppmc.c?
[19:07:40] <micges-dev> skunkworks: I'll try to run driver in uspace tomorrow
[19:08:00] <jepler> dgarr: yes, I have not touched any drivers but the ones specifically listed in my e-mail (serport, hostmot2, hm2_pci, hm2_test)
[19:08:28] <jepler> dgarr: for userspace EPP, it will be necessary to create some new APIs to regularize the hardware access between userspace and kernel
[19:08:47] <dgarr> i have a wheezy partition now and could test hal_ppmc if you work on it
[19:09:21] <jepler> dgarr: I'll keep that in mind. I have a mesa epp card, but not parport in my testing computer
[19:09:25] <jepler> I should pick one up, I guess.
[19:10:02] <jepler> dgarr: you've been with us for a long time, maybe you're about ready to start writing realtime hardware driver code. Yes?
[19:13:19] <dgarr> maybe but i have many projects going already
[19:17:05] <jepler> I know the feeling. It was mostly said in good fun.
[19:17:25] <jepler> .. just the slighest bit of seriousness, because I am confident you could learn if you cared to
[19:18:10] <jepler> OK, with only a few conflicts, the commits in the range origin/unified-build-candidate-3..origin/ubc3-7i80 cherry-pick to rtos-uspace-apis. If it builds, I'll push it in since it sounds like skunkworks dreams of testing it
[19:18:39] <jepler> .. what better to do on a sunday evening anyway
[19:18:39] <skunkworks> sure - I can test that.
[19:18:43] <skunkworks> heh
[19:23:01] <jepler> halcmd: loadrt hm2_eth
[19:23:01] <jepler> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
[19:23:01] <jepler> <stdin>:2: /home/jepler/src/linuxcnc/bin/rtapi_app exited without becoming ready
[19:23:07] <jepler> I think this is about as far as I'll get without hardware.
[19:24:20] <skunkworks> nice!
[19:25:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth bd3f91c 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=bd3f91c
[19:25:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth f3a7eac 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=f3a7eac
[19:25:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 2740694 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=2740694
[19:25:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth e531abf 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=e531abf
[19:26:01] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth aa00c55 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=aa00c55
[19:26:05] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth e977d6c 06linuxcnc 10(6 files in 2 dirs) stuff that should be squashed into earlier commits. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e977d6c
[19:26:08] <jepler> ^^^ this is rough and is not likely to be merge-quality stuff.
[19:26:11] <jepler> afk
[20:29:53] <cradek> dgarr: gcc: gcc (Debian 4.7.2-5) 4.7.2
[20:31:15] <cradek> dgarr: this version of gcc is buggy building with some compiler flags. I think 2.6.0~pre4 does NOT have the fix
[20:31:29] <cradek> let me figure out where the fix is...
[20:32:05] <cradek> yep it's right after 2.6.0~pre4, ref of the fix is 5bbab25f8
[20:32:18] <cradek> dgarr: it would be great if you would pull in that fix and test
[20:33:53] <cradek> jepler: let me know if I can help with hardware. I have various parport stuff but no hm2_eth type hardware.
[20:35:03] <cradek> dgarr: scripts/linuxcnc_info is awesome for this, and I didn't know about it
[20:35:13] <dgarr> cradek: thanks i will test later this evening and report back
[20:35:54] <dgarr> scripts/linuxcnc_info is accessible from pickconfig under configs/apps/
[20:37:04] <cradek> slick
[21:02:38] <jepler> cradek: from the dmesg, I don't think dgarr's machine even got to the point of running the linuxcnc code that had that problem
[21:03:17] <cradek> I was running master, and he's running 2.6, so I thought maybe the symptoms could be different?
[21:03:22] <jepler> dgarr: is it a machine that needs "lapic" on the kernel commandline? some googling I did indicated that not running with APIC could be related
[21:04:31] <jepler> cradek: none of the stack frames are linuxcnc. it's possible that rtai itself is affected, though I thought having floating-point function parameters was related, and those stack frames don'e look like they would have
[21:04:59] <jepler> in fact no linuxcnc kernel module is loaded yet
[21:05:21] <jepler> cradek: if you have a parport pci card, I'd borrow it.
[21:06:30] <dgarr> my test just finished using commit 5bbab25f8, same Oops result
[21:07:02] <dgarr> on same machine, with lucid, rtai i never used lapic option that i know of
[21:07:08] <cradek> dgarr: are you running the 486 or the 686-pae version?
[21:07:14] <dgarr> 686
[21:07:47] <cradek> hmm, not good. darnit.
[21:08:57] <jepler> dgarr: does the same problem occur with the rtai latency test?
[21:12:30] <dgarr> # rmmod rtai_hal
[21:12:30] <dgarr> Error: Module rtai_hal is in use
[21:13:09] <dgarr> i have to reboot i guess --- rtai latency test that is part of rtai? do you know the name
[21:13:16] <jepler> jas
[21:13:33] <jepler> I think it's somewhere under /usr/realtime
[21:13:59] <jepler> /usr/realtime-3.4-9-rtai-686-pae/testsuite/kern/latency/
[21:14:11] <jepler> I think the incantation is cd there; sudo ./run
[21:15:32] <jepler> and my guess is that it won't work and you'll have a similar or identical dmesg
[21:19:07] <dgarr> identical oops with kern/latency/run (I-pipe: could not find timer for cpu #0)
[21:20:58] <jepler> dgarr: Any messages about apic at boot? dmesg | grep -i apic or so
[21:23:43] <dgarr> dmesg|grep -i apic appended to www.panix.com/~dgarrett/stuff/3.4-9-rtai.txt
[21:23:51] <jepler> I *believe* that the real problem is: I-pipe: could not find timer for cpu #0
[21:24:08] <jepler> the crash in ipipe_timers_release is because they made a mistake in timer cleanup when no timer was found
[21:24:22] <jepler> .. so while it would be nice if it didn't Oops in that case, it's not the real problem
[21:25:32] <jepler> in their kernel patch, the fix for the subsequent crash might be along the lines of
[21:25:35] <jepler> [3$ +static void ipipe_timer_release_sync(void)
[21:25:38] <jepler> +{
[21:25:40] <jepler> + struct ipipe_timer *timer = __ipipe_this_cpu_read(percpu_timer);
[21:25:43] <jepler> +
[21:25:46] <jepler> ++ if(timer)
[21:25:48] <jepler> + timer->release(timer);
[21:26:06] <jepler> i.e., check timer is non-NULL before calling its ->release method
[21:27:37] <jepler> might try booting with the lapic flag in case it changes anything
[21:28:54] <dgarr> i'll try lapic flag now, i wonder if there are any apic options that would help find the timer?
[21:35:26] <dgarr> same Oops with lapic (BOOT_IMAGE=/vmlinuz-3.4-9-rtai-686-pae root=UUID=fc07f0a1-747e-4827-902c-317ed03ca4cf lapic ro)
[21:36:33] <jepler> dgarr: hmph, OK
[21:37:38] <dgarr> what compiler version was used for vmlinuz-3.4-9-rtai-686-pae stuff i wonder if that could matter?
[21:40:31] <jepler> I assume the same gcc 4.7
[21:42:36] <jepler> can you pastebin /proc/timer_list ?
[21:42:40] <jepler> .. booted in that kernel
[21:46:18] <jepler> now reading rtai source for where this comes from [ 0.172013] I-pipe: cannot use LAPIC on cpu #0 as a tick device
[21:47:41] <dgarr> /proc/timer_list appended to
http://www.panix.com/~dgarrett/stuff/3.4-9-rtai.txt
[21:49:55] <jepler> + if (!(lapic_clockevent.features & CLOCK_EVT_FEAT_DUMMY))
[21:49:55] <jepler> + levt->ipipe_timer = &__get_cpu_var(lapic_itimer);
[21:49:57] <jepler> + else {
[21:50:00] <jepler> + printk(KERN_INFO
[21:50:00] <jepler> + "I-pipe: cannot use LAPIC as a tick device\n");
[21:50:34] <jepler> so the kernel has apparently marked your lapic as a "dummy"
[21:51:11] <jepler> the internet says:
[21:51:12] <jepler> > >>> Xenomai sends this message if C1E option is enabled in a BIOS. To fix
[21:51:15] <jepler> > >>> this issue please disable C1E support in the BIOS. In some Award BIOS
[21:51:18] <jepler> > >>> this option is located in the +Advanced BIOS Features->+ menu (+AMD
[21:51:21] <jepler> > >>> C1E Support+).
[21:51:23] <jepler> I suspect that this check didn't exist in old rtai
[21:52:27] <dgarr> i will go look at bios
[21:53:47] <jepler> kernel parameter apic=debug may provide additional information in dmesg
[22:00:02] <linuxcnc-build> build #2203 forced
[22:00:03] <linuxcnc-build> I'll give a shout when the build finishes
[22:07:18] <dgarr> bios: Phoenix Award WorkstationBIOS v6.00PG -- i found no C1E references but toggle ACPI function (dis->en) same Oops, restored, then toggled IOAPIC (en->dis) same Oops will dry apic=debug next
[22:17:50] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 18ba83f 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=18ba83f
[22:17:50] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 51d31d0 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=51d31d0
[22:17:50] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 516ae81 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=516ae81
[22:17:54] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 576c331 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=576c331
[22:17:59] <KGB-linuxcnc> 03Michael Geszkiewicz 05origin/jepler/rtos-uspace-hm2-eth 59fde40 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=59fde40
[22:18:03] <KGB-linuxcnc> 03Jeff Epler 05origin/jepler/rtos-uspace-hm2-eth f4c3079 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=f4c3079
[22:18:21] <jepler> (just about the same as last time, but I squashed the last commit into the earlier commits where it belonged, and fixed a 64-bit printf bug)
[22:18:41] <jepler> dgarr: I'm heading out for the night. thanks for spending time trying to troubleshoot that computer..
[22:20:13] <jepler> dgarr: give me a poke if I don't mention looking at the dmesg with apci=debug
[22:52:36] <skunkworks> robs talk was pretty cool - the video is up.
https://www.youtube.com/watch?v=412N5A-N8Fc
[22:52:52] <cradek> skunkworks: did you get to go to the thing?
[22:53:09] <skunkworks> yes - it was nice. tormachs facility is pretty neat
[22:53:25] <cradek> cool!
[22:54:14] <skunkworks> rob had a neat way to figure out the blend arc for arc-arc (and a lesser extent line-arc) transitions that didn't require solving quadratic equations.
[22:54:45] <cradek> the blend arc between helixes seems pretty darn hard to me
[22:54:54] <cradek> he must be awfully clever
[22:55:04] <skunkworks> I don't think he does helixes yet..
[22:55:09] <skunkworks> (I don'
[22:55:17] <skunkworks> (atleast I don't think..)
[22:55:32] <skunkworks> wait - what do you mean by helixes?
[22:56:04] <cradek> arcs with added motion perpendicular to the plane
[22:56:16] <cradek> like thread milling
[22:56:40] <skunkworks> ah - I think that falls back to parabolic blending
[22:57:26] <cradek> ahh
[22:57:37] <cradek> I bet contouring speed doesn't really ever matter for helixes
[22:58:06] <skunkworks> got to meet len shelton from probix - also the guy who designed the beaglebone was there.
[22:58:48] <skunkworks> god - I have to go to bed.
[23:03:51] <linuxcnc-build> Hey! build 0000.checkin #2203 is complete: Success [3build successful]
[23:03:52] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2203
[23:37:36] <dgarr> jepler: thanks for your help,
http://www.panix.com/~dgarrett/stuff/3.4-9-rtai_kern.log_apic=debug