Back
[02:41:11] <KGB-linuxcnc> 03seb 05v2.5_branch 9c8f24c 06linuxcnc 10docs/man/man9/motion.9 * docs: fix a typo in the motion manpage
[04:02:18] <memleak> seb_kuzminsky, master branch is at least working now
[04:02:48] <memleak> not in a perfect state, still need more time to work on it but i'm really tired, i'll take a shot at it tomorrow
[08:23:40] <jepler> seb_kuzminsky: that's a weird problem (5i20)
[08:24:17] <jepler> remind me next week to look at your mm/in problem too
[08:30:45] <cradek> jepler: good morning
[08:35:00] <cradek> ok I scrolled back far enough to find the screenshot
[08:35:09] <cradek> not clear to me what's going on there, would love more information (and also a test on 2.5)
[10:38:08] <KGB-linuxcnc> 03seb 05v2.5_branch fe7cfe2 06linuxcnc 10docs/src/code/Style_Guide.txt * docs: fix code style examples
[10:54:30] <cradek> man that file is full of snark
[10:58:39] <cradek> it's about 50/50 good advice/unnecessary obnoxiousness
[11:02:28] <cradek> do not use cute names a shooting offense brain damaged Microsoft makes buggy programs function-growth-hormone-imbalance syndrome less-than-gifted first-year high-school student You know you're brilliant heated debates emacs versus vi
[11:03:00] <archivist> vi!
[11:07:06] <skunkworks> edlin
[11:07:36] <archivist> edlin was bad :)
[11:07:44] <skunkworks> I know :)
[11:09:42] <seb_kuzminsky> yeah that sucks :-(
[11:12:30] <KGB-linuxcnc> 03chris 05master ce9835a 06linuxcnc 10VERSION 10debian/changelog * Release 2.5.3
[11:12:30] <KGB-linuxcnc> 03jthornton 05master 0ad42cb 06linuxcnc 10docs/ 10src/gui/axis.txt 10src/lathe/lathe-user.txt * Docs: add more links and info about tool change
[11:12:33] <KGB-linuxcnc> 03andy 05master 5a82cec 06linuxcnc 10src/hal/drivers/pcl720.comp
[11:12:35] <KGB-linuxcnc> Use the correct type of "not" operator when creating the complementary output pin.
[11:12:44] <KGB-linuxcnc> 03seb 05master 9c8f24c 06linuxcnc 10docs/man/man9/motion.9 * docs: fix a typo in the motion manpage
[11:12:50] <KGB-linuxcnc> 03seb 05master fe7cfe2 06linuxcnc 10docs/src/code/Style_Guide.txt * docs: fix code style examples
[11:12:56] <KGB-linuxcnc> 03seb 05master 46d8ef5 06linuxcnc 10docs/ 10man/man9/motion.9 10src/gui/axis.txt * Merge remote-tracking branch 'origin/v2.5_branch'
[11:13:03] <cradek> I'd fix it but am afraid I'd just delete most of it, because deep down inside I feel style guides are just wankery. Do no harm (always think about what will make VC work the best) should be the whole of the style guide.
[11:13:40] <cradek> that's where people need the most guidance
[11:14:13] <cradek> while if() vs if () is a great big who cares
[11:15:28] <cradek> </rant>
[11:15:30] <cradek> sorry
[11:16:23] <seb_kuzminsky> this is why i love ed nisley's blog:
[11:16:35] <seb_kuzminsky> title: "Precision Wrench Rebuild"
[11:16:44] <cradek> haha
[11:16:48] <seb_kuzminsky> teaser sentence: "So I sawed off a strip of bedframe steel that fit the nuts better"
[11:17:43] <seb_kuzminsky> bbl
[11:33:16] <norbert> Halo, I found the following problem on axis, running on a fresh masterand also on 2.5.3. After homing I entered in MDI mode M61Q2, I got no error, but the tool will not be changed. I do know, that it does work on a 2.4 system and if I give the same command with gmoccapy through emc.command it does work. Can someone confirm?
[11:35:38] <andypugh> Axis doesn't display the tool number, but the tool-in-spindle pin will change.
[11:35:55] <andypugh> So, it is an issue with Axis not updating, not with G61 not working.
[11:41:09] <andypugh> If it is important to you for Axis to display the tool number I am not sure what the solution is. But it you are trying to set initial state to keep the toolchaner happy then M61 ought to be OK.
[11:52:51] <seb_kuzminsky> doesn't axis show the current tool number down at the bottom normally?
[12:00:30] <norbert> Yes, and it worked fine in 2.4, but now you don't know if the tool change has been successful. IMHO it is a bug, also the preview don't show the right tool.
[12:05:15] <norbert> OK, I checked a little bit more, and is definitly a bug, because if you say M61Q2, iocontrol.0.tool-number will change to 2, if you than say G43, the motion.tool-offset-z should change, but it will remain 0, that is very dangerous!!
[12:08:24] <seb_kuzminsky> could you try it with m6 instead of m61? i fixed some bugs with m6 in 2.5 a while back
[12:09:21] <norbert> T2 M6 and G43 work fine!
[12:10:03] <seb_kuzminsky> i would believe m61 is buggy... :-(
[12:11:25] <norbert> I agree a little bit, but it does work fine with gmoccapy, I just emit the code through emc. So it is not the M61, but the interaction with manual tool change?
[12:12:01] <norbert> axis seems not to reakt to tool change signals
[12:12:54] <seb_kuzminsky> axis reacts to tool change when using m6, but not when using m61, is that right?
[12:12:54] <ktchk> I installed the new realtime operating system xenomai but latency is 3582875 ns machine is dwell vostro 1510
[12:14:53] <norbert> @sep_kuzminski: That is exactly right!
[12:15:57] <pcw_home> thats impressive: probably about ~5 million cycles of CPU thumb twiddling
[12:16:55] <seb_kuzminsky> norbert: would you open a bug report for this on sourceforge please?
https://sourceforge.net/p/emc/bugs/
[12:18:23] <norbert> immediate!, I do it rigth now!
[12:20:30] <norbert> sep, are you the owner?
[12:24:58] <seb_kuzminsky> you can assign it to me if you like, i'll take a look at it
[12:25:33] <norbert> Done!
[12:26:21] <seb_kuzminsky> thanks :-)
[12:32:10] <ktchk> can the xenomai linuxcnc drive a stepper breakout board?
[12:40:38] <skunkworks> ktchk, it should be able to
[12:41:18] <skunkworks> I have not actually tested real hardware - but I have run the stepper configs on 12.04 xenomai
[12:41:20] <ktchk> skunkworks: will xenomai be long term?
[12:41:30] <skunkworks> I think that is the plan..
[12:42:02] <skunkworks> it seems to be on par with rtai latency tests.
[12:42:54] <ktchk> skunkworks: but it is slow my latency test is 3582875
[12:43:04] <skunkworks> that is poor.
[12:43:35] <ktchk> skunkworks: I thing i have to find a amd cpu laptop
[12:43:49] <skunkworks> I have systems here that run <10us
[12:44:00] <ktchk> what cpu
[12:44:03] <skunkworks> laptops are normally not a good canidate...
[12:44:10] <skunkworks> amd
[12:44:29] <skunkworks> although I have tested it on a few intel systems with varying results.
[12:45:02] <ktchk> amd and intel m
[12:45:04] <ktchk> just no p4
[12:45:20] <skunkworks> I found 'idle=poll' in the kernel line to help quite a bit. also disabling sound.
[12:46:05] <ktchk> but will one day rtai will be back
[12:46:16] <skunkworks> they are working on it...
[12:46:28] <skunkworks> but it isn't there yet
[12:46:54] <ktchk> last night i test with hart
[12:47:38] <ktchk> toolbox rtai
[12:47:51] <skunkworks> seb has been playing with rtai
[12:47:52] <skunkworks> http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[12:48:43] <skunkworks> it doesn't work correctly with mesa pci interface cards yet... but they are working on it.
[12:49:12] <ktchk> stepper is more simple
[12:50:21] <skunkworks> what are you making?
[12:50:51] <ktchk> small chinese router with laptop
[12:51:33] <ktchk> hong kong small house can not house big machine
[12:51:42] <skunkworks> again - it might be hard to get a laptop to perform well with realtime.
[12:52:29] <ktchk> I do use few working well sony fujitsu but must intel m cpu
[12:53:44] <ktchk> parellel port is ok with pcmcia card,which is made in china and real address port
[13:14:47] <andypugh> My Atom board is showing 14uS (14000nS) latency with Xenomai. Pretty much the same as RTAI
[13:17:36] <ktchk> I have a amd board with a plugin video board 10000ns RTAI 10.04
[14:00:41] <CaptHindsight> andypugh: what versions of kernel, xenomai, linuxcnc etc are you using with that 14uS Atom board?
[14:02:52] <CaptHindsight> we need to put up a chart somewhere, too many apples to oranges comparisons and misinformation over what kernel with what realtime and now what architecture
[14:07:32] <CaptHindsight> skunkworks: as far as I know that RTAI PCI issue is only related to the (5i20) so far
[14:08:01] <skunkworks> that is my understanding too
[14:10:23] <CaptHindsight> putting together a 7-axis servo system here along with the 3.4 kernel and RTAI using 6i25
[14:11:05] <skunkworks> CaptHindsight, are you lateforsupper?
[14:11:31] <memleak> skunkworks, just so you know, RTAI works fine with RTAI, seb_kuzminsky's problem is a PCI issue specific to his hardware.
[14:11:41] <CaptHindsight> I told you never to call me that :)
[14:11:44] <memleak> RTAI works fine with linuxcnc I meant.
[14:11:47] <skunkworks> ok :)
[14:13:51] <cradek> seb's hardware is surely normal hostmot2-supported hardware
[14:14:00] <CaptHindsight> looking for RTAI testers on more hardware
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[14:14:41] <memleak> cradek, yeah but the motherboard might have a flaky BIOS or something or a flaky PCI controller or whatever else.
[14:15:14] <cradek> well that seems pretty unlikely to me, but whatever
[14:15:18] <cradek> more testing will tell
[14:15:33] <cradek> have you run any hardware yourself?
[14:16:12] <memleak> Just FYI, i have a board next to me that is a 50 dollar AMD 785 board from BIOSTAR and it throws enough spurious interrupts over USB that it can crash a running fedora system.
[14:17:49] <memleak> so it's not really unlikely that a bad BIOS or something could severely mess up PCI. it's actually hard for me personally to find "good" BIOSes without resorting to coreboot.
[14:18:42] <seb_kuzminsky> this board that has the linux 3.4 + rtai pci weirdness runs lucid rtai just fine, so i think the hardware is ok
[14:19:12] <memleak> lucid is 2.6.x based, yes?
[14:19:17] <cradek> I'm pretty sure we have never heard of a bios problem that made the hm2 pci cards not work on certain motherboards. (EPP problems we've definitely heard of)
[14:20:02] <memleak> a lot of PCI code in the kernel has changed since 2.6.x to 3.x
[14:20:05] <cradek> yes lucid is 2.6, and the rtai kernel all our users are using is 2.6
[14:20:34] <memleak> if it doesn't work in 3.4, i highly doubt anything is going to change in 3.2
[14:20:48] <cradek> we're talking past each other
[14:20:53] <memleak> 3.5.7 is ancient so maybe that.
[14:21:18] <cradek> I understood you were saying seb's problem is probably hardware - but that would be incorrect because it is *known good* hardware
[14:21:35] <memleak> maybe 3.4 exposed the PCI bug :P
[14:21:40] <cradek> I'm sorry if I misunderstood, please clarify?
[14:22:11] <memleak> cradek, seb_kuzminsky asked me to port RTAI to 3.2 but i highly doubt that'll fix anything
[14:22:26] * memleak checks the changelog from 3.4.53 to 3.4.55
[14:22:42] <cradek> ok there are two different conversations going on
[14:23:34] <memleak> what did you misunderstand?
[14:23:48] <cradek> I agree it would be great if we had a patch for the kernel version that precise uses
[14:24:05] <memleak> precise uses 3.2?
[14:24:06] <cradek> what I typed above about hardware
[14:24:44] <cradek> yes mine says 3.2.0-40
[14:32:15] <seb_kuzminsky> hi zultron, how's life?
[14:36:31] <seb_kuzminsky> memleak: i booted that 3.4.53-1-rtai kernel with "pci=nommconf", but it still behaved the same way
[14:36:57] <seb_kuzminsky> i disabled CONFIG_PCI_MMCONFIG and build a -2-rtai kernel, haven't tried it yet (but it's in that rtai-for-3.4-prerelease directory on my web server)
[14:41:01] <seb_kuzminsky> ah, cradek, there was one bios bug that caused hm2 problems
[14:41:08] <seb_kuzminsky> but i fixed it in the driver
[14:41:18] <memleak> I CALLED IT!!!
[14:42:12] <cradek> haha that makes my day
[14:42:19] <seb_kuzminsky> err
[14:42:44] <memleak> seb_kuzminsky, while you're in the kernel config screen change the default probe method or whatever to direct
[14:43:09] <seb_kuzminsky> i wish i had a pci sniffer
[14:43:09] <memleak> there should be direct, mmconfig, bios, and....
[14:43:23] <seb_kuzminsky> yeah, for -2-rtai i turned off everything by direct
[14:43:42] <memleak> by direct?
[14:43:48] <seb_kuzminsky> but
[14:43:52] <memleak> ok :)
[14:43:58] <seb_kuzminsky> i dont grammar good
[14:44:02] <memleak> :P
[14:45:10] <seb_kuzminsky> it looks to me like outgoing pci writes get corrupted
[14:45:34] <seb_kuzminsky> i see the correct value go into memcpy
[14:45:37] <memleak> seb_kuzminsky, you can also specifiy pci=nobios
[14:45:49] <seb_kuzminsky> then when i read them back from the fpga i get a different answer
[14:45:57] <seb_kuzminsky> and reading it over and over again doesn't change the value i get back
[14:46:11] <memleak> are you using IOMMU or MMIO in HPET?
[14:46:19] <seb_kuzminsky> but if i write a new value and read again, i get a different random(?) number that stays consistent until i write again
[14:46:30] <seb_kuzminsky> not sure
[14:46:47] <memleak> if possible turn those options off as well.
[14:46:59] <memleak> this is all documentented in my 32-bit kernel config on the RTAI site.
[14:47:06] <memleak> er.. github branch
[14:47:49] <seb_kuzminsky> i tried building your rtai_32_defconfig first, but it lacked virtio drivers so next i tried my 3.5.7 config
[14:48:00] <seb_kuzminsky> i should maybe try your config with the addition of virtio instead
[14:48:19] <memleak> virtio sounds very bad for PCI read and writes..
[14:48:32] <memleak> why are you doing this on a VM again and expect no issues?
[14:48:38] <seb_kuzminsky> though it'd be best if our kernel config was as close as possible to the ubuntu kernel config - it's been designed to work with the widest possible range of hardware
[14:49:03] <memleak> I can tweak the ubuntu kernel config to RTAI without a problem
[14:49:05] <seb_kuzminsky> i use virtio when i run in a vm, when you run the same kernel on bare metal the virtio drivers are unused of course
[14:49:36] <seb_kuzminsky> all the pci issues i've been talking about have been on bare metal
[14:49:48] <memleak> are your PCI issues being causes in or out of the VM?
[14:49:54] <memleak> *caused
[14:49:55] <seb_kuzminsky> out of the vm
[14:50:09] <seb_kuzminsky> i've neveer tried to talk to real hardware from within a VM
[14:50:26] <memleak> ok. surely you know better to control your machine via linuxcnc inside virtualbox :P
[14:50:27] <seb_kuzminsky> i just do my early testing in there - make sure it boots and the debs install and linuxcnc builds & runtests passes
[14:50:37] <seb_kuzminsky> indeed i do ;-)
[14:51:09] <seb_kuzminsky> but is sure is convenient for some kinds of testing while on the bus ;-)
[14:51:28] <memleak> i'll do a 3.2 RTAI port for your guys but please do not backport any ubuntu patches into it
[14:51:52] <memleak> also your PCI issue will most likely still be present if its in 3.2
[14:51:54] <seb_kuzminsky> thanks!
[14:52:07] <seb_kuzminsky> i dont know where the pci issues are coming from yet
[14:52:12] <memleak> I'll also base the configs off an ubuntu kernel
[14:52:18] <memleak> both 64 and 32
[14:52:30] <seb_kuzminsky> i suspect something not getting initialized correctly in the pci config maybe?
[14:52:32] <memleak> i'm very sick thought today so i dont think now is the time to do it
[14:52:58] <seb_kuzminsky> hmm, i should dump the pci config space from linux 2.6.32-rtai where it works and 3.4.51-rtai where it does not work...
[14:53:19] <memleak> you have a dream about being hungover, and you wake up the next morning and your dream comes to life.
[14:53:32] <memleak> that would actually help a lot maybe!
[14:54:21] <memleak> seb_kuzminsky, you still havent posted your dmesg :)
[14:54:32] <seb_kuzminsky> i'll post them tonight
[14:54:45] <memleak> if possible, dump a dmesg on both 2.6 lenny precise w/e and 3.4 RTAI
[14:55:01] <seb_kuzminsky> lolwut
[14:55:32] <memleak> dump a dmesg on he linuxcnc livecd and then dump the dmesg output on 3.4 RTAI
[14:55:56] <memleak> then we can compare the PCI debug data and such.
[14:55:58] <seb_kuzminsky> oh sure
[14:56:13] <memleak> also an lspci -nnnnnnvvvvvvvv
[14:56:20] <memleak> both in linuxcnc and RTAI 3.4
[14:56:38] <memleak> linuxcnc livecd i meant
[14:57:11] <memleak> im really messed up i should get off IRC
[14:57:27] <seb_kuzminsky> dude go drink some electrolytes and sleep
[16:19:13] <andypugh> CaptHindsight: Its a DN2800 running Ubuntu 12.04.2 LTS (GNU/Linux 3.5.7-xenomai-2.6.2.1 x86_64)
[16:24:33] <andypugh> seb sending him away to drink battery acid seems a bit harsh
[16:31:59] <seb_kuzminsky> puts hair on your chest
[17:50:27] <andypugh> How do I pull stuff from the mah repo?
[17:50:56] <andypugh> Do I need to clone the whole thing into a separate directory?
[17:58:49] <seb_kuzminsky> you can either clone mah's repo into a new local repo, or you can add his repo as a remote in an existing g.l.o repo
[18:01:38] <andypugh> Ah! Yes, "remote" that's the word. Thanks
[18:02:30] <seb_kuzminsky> sure
[18:02:34] <seb_kuzminsky> now go drink battery acid
[18:03:30] <andypugh> Will you let me off with Single Malt?
[18:03:44] <cradek> only if you share
[18:03:59] <andypugh> Of course, come on round. Any time.
[18:05:53] <andypugh> Now, where does gitweb tell you what the git URL is?
[18:06:18] <andypugh> Ah, got it, I think.
[18:07:47] <andypugh> No, I spoke too soon.
[18:07:49] <andypugh> andypugh@precise:~$ git remote add git://git.mah.priv.at/emc2-dev.git
[18:07:50] <andypugh> fatal: Not a git repository (or any of the parent directories): .git
[18:09:56] <cradek> do it inside your repo
[18:10:20] <cradek> and you need to specify a nickname for the remote
[18:10:39] <cradek> git remote add mah git://...
[18:12:02] <andypugh> andypugh@precise:~$ git remote add mah git://git.mah.priv.at/emc2-dev.git
[18:12:02] <andypugh> fatal: Not a git repository (or any of the parent directories): .git
[18:12:30] <cradek> do it inside your repo
[18:13:13] <andypugh> I think I might need to ritually disembowel myself first.
[18:13:26] <cradek> eh, have another drink instead
[18:14:18] <andypugh> Maybe a better idea. But you said I should do it, and I didn't do it. I wasted a minute of your life, a debt I can never repay.
[18:14:39] <andypugh> Thanks, worked a treat.
[18:16:13] <cradek> haha
[18:26:53] <cradek> what the hell!? did sascha actually fix multiple UIs correctly?
[18:28:04] <cradek> his patch looks very promising but is totally over my head
[18:28:05] <andypugh> que?
[18:28:16] <cradek> http://sourceforge.net/p/emc/bugs/328/
[18:29:30] <cradek> see his other patches too...
[18:29:46] <andypugh> It goes over my head too. I am thinking 'Dude, you have a new job"
[18:29:51] <cradek> wonder who this is - he sure seems to know what's going on
[18:29:54] <cradek> no kidding
[18:30:22] <cradek> bbl after dinner
[18:41:05] <seb_kuzminsky> sascha ittner is an open-source contributor and a custom oscilloscope-clock maker that i'd never heard about before today
[19:47:30] <seb_kuzminsky> memleak:
http://highlab.com/~seb/linuxcnc/rtai-pci/
[19:47:45] <seb_kuzminsky> there's dmesg & lspci from the 3.4 kernel, i'm installing lucid on that machine now...
[19:56:01] <memleak> lots of nasty kernel config options set..
[19:57:23] <jepler> "configures emcCommand as a queue instead of a buffer." -- I have a memory that alex j tried this at one point but problems that I don't recall cropped up ..
[20:02:16] <jepler> it's unfortunate that this apparently requires changing every nml-using UI
[20:02:27] <jepler> - m.serial_number = next_serial(s);
[20:02:27] <jepler> - s->c->write(m);
[20:02:28] <jepler> - emcWaitCommandReceived(s->serial, s->s);
[20:02:28] <jepler> + emcSendCommand(s, m);
[20:02:38] <jepler> this raft of changes is good and could be split to a separate commit
[20:02:46] <jepler> factoring out code that is repeated over and over again
[20:05:22] <jepler> ;
[20:05:23] <jepler> + int serial_diff = stat->echo_serial_number - s->serial;
[20:05:23] <jepler> + if(s->s->peek() == EMC_STAT_TYPE &&
[20:05:23] <jepler> + serial_diff >= 0) {
[20:05:23] <jepler> + return 0;
[20:05:35] <jepler> this is concerning, because it pulls out stat->echo_serial_number before the peek
[20:05:50] <jepler> but maybe that only delays things by one iteration of the loop
[20:06:21] <memleak> seb_kuzminsky, updating 3.4 support and configs, basing it off ubuntu
[20:06:49] <jepler> and technically speaking that happens to depend on undefined signed integer overflow when serial wraps around
[20:07:01] <memleak> i'll let you know when the patch is done
[20:07:37] <jepler> we don't care about that, and will probably specify -fno-strict-overflow the first time we identify it as assbiting
[20:09:21] <jepler> but tbh I don't see where the serial number is set now in emcmodule.cc
[20:10:08] <jepler> I'd want to valgrind it, except that it's a stack-allocated object so valgrind usually doesn't detect used-uninitialized errors
[20:13:38] <andypugh> Also, mah seems to want to kill nml, so perhaps that will swap the current bugs for more interesting ones.
[20:14:10] <jepler> this patch is potential 2.6 material, deleting nml is not.
[20:14:42] <jepler> ah here's where the serial number gets set, down at RCS_CMD_CHANNEL::write
[20:15:49] <andypugh> (Tellingly, the guy who I think put nml in there wants to see it dead, which sounds like an endorsment). But (catching up) is no solution.
[20:18:06] <jepler> seb_kuzminsky: hey remember when SIGPIPE was causing you trouble? more trouble in src/libnml/buffer/tcpmem.cc using signal()
[20:21:45] <jepler> I would have to bang on it before I was confident the new way of getting a serial number was really not racy
[20:22:17] <jepler> ... it seems like two clients could have the same header.write_id
[20:23:13] <jepler> /* Produce error message if process does not have permission to read. */
[20:23:16] <jepler> if (!write_permission_flag) {
[20:23:19] <jepler> tee hee
[20:27:36] <jepler> I guess if the access is guarded by a semaphore, which maybe it is at least in shmem...
[20:28:11] <jepler> yes default mutex is OS_SEM_MUTEX
[20:29:19] <andypugh> Interesting: Google sends me to :
http://www.linuxcnc.org/index.php/italian/about/6-emc-history which is a page in english. (and quite an interesting one). But the URL is italian. If I click the "Succ." link I get a page in Italian. As I don't speak italian, I naturally then click the bottom-left link "English" and get <err, actually, this time, exactly the page I expect.> How the heck I ended up from Google "pro
[20:29:20] <andypugh> nml emc2" to "board of directors" only by clicking "Succ:" and "English" seems fated to remain a mystery.
[20:30:37] <jepler> virtual CMS_STATUS clear(); /* Has the buffer been read recently? */
[20:30:37] <jepler> virtual int check_if_read(); /* Has the buffer been read recently?
[20:30:40] <jepler> */
[20:30:42] <jepler> virtual int get_msg_count(); /* Has the buffer been read recently?
[20:30:45] <jepler> */
[20:30:51] <jepler> nice documentation
[20:32:34] <jepler> anyway it looks like tcpmem won't provide the atomic guarantee but shmem will, so in adopting this change we should ask whether we think we're regressing any actual users over tcp, or just imaginary ones
[21:00:07] <seb_kuzminsky> memleak: the logs & stuff from lucid are up
[21:00:23] <seb_kuzminsky> the lspci output is the same, except i forgot sudo on precise so the capabilities are missing
[21:24:19] <memleak> 3.4.55 support bumped
[21:25:14] <memleak> 3.2 is going to be awhile
[21:25:59] <memleak> in the meantime i'll post updated configs based off of ubuntu
[21:26:04] <seb_kuzminsky> cool
[21:27:13] <memleak> does xenomai work on 64-bit btw? anyone here know?
[21:27:37] <seb_kuzminsky> we ran xenomai in 64-bit at the hackfest
[21:27:46] <memleak> latency was good?
[21:28:33] <seb_kuzminsky> i'm not sure
[21:28:45] <memleak> if it worked at all with linuxcnc then most of the work i need to do with the 32/64-bit unification code is all outside the kernel
[21:28:46] <seb_kuzminsky> i think xenomai latency is often comparable to our lucid rtai latency
[21:29:04] <memleak> yes but in 64-bit is the question ;)
[21:29:14] <andypugh> Yes, I am running Xemonai 64 bit on a DN2800 atom board and oit almost works.
[21:29:21] <KGB-linuxcnc> 03seb 05build-deb-without-de-pl 2c5fe74 06linuxcnc 10debian/configure * deb: don't build-depend on texlive's german and polish localizations
[21:29:40] <memleak> almost works? whats wrong with it?
[21:30:43] <andypugh> Can't (currently) make the 5i65 work.
[21:31:13] <andypugh> Sorry, I mean 6i25
[21:31:54] <andypugh> But, LinuxCNC runtests works, and latency test shows 14k
[21:32:07] <memleak> if the real-time system loads at all then all the issues RTAI is having with 64-bit is userspace stuff
[21:32:23] <memleak> (/usr/realtime)
[21:32:46] <memleak> so thats easy to fix then! thanks andypugh
[21:35:09] <andypugh> Until I installed I wasn't even sure it was a 64-bit board,
[21:36:45] <andypugh> I created this config because I know that the Mesa 7i49 driver is broken in 64 bit systems.
[21:38:29] <andypugh> As I copied the code that promotes 32-bit FPGA registers to 64-bit accumulators from an (ill-remebered) other driver I suspect that the problem exists in more than one place.
[21:39:15] <seb_kuzminsky> i wonder how much of our 32/64-bit realtime brokenness clang and coverity will pick up when we start doing those builds
[21:39:18] <seb_kuzminsky> bbl
[21:40:50] <andypugh> is it possible to find out now?
[21:40:58] <memleak> seb_kuzminsky, 64-bit real-time will really just be 32-bit real-time with 64-bit instructions.
[21:41:30] <memleak> currently 64 and 32 do completely different things, i've been working on that for awhile.
[21:44:26] <andypugh> The problem I coded in (because I am incompetent) is assuming that "long" is signed 32 and "long long" is signed 64. Abd adding (new_32) - (old_32) to acum_64 "Just Works" as long as new_32 and old_32 are explictly 32 bits rather than "long"
[21:45:57] <memleak> Looks like paolo is doing the same thing as me..
[21:46:07] <memleak> he's unifying them as well.. >_>
[21:55:47] <memleak> I always hate when developers go off and do their own thing and not work together, but now I'm being forced to be one of those developers because nobody is working with me. :/
[23:20:03] <memleak> this 3.2 RTAI port is a lot harder than I expected..
[23:36:26] <memleak> it compiles but i highly doubt this is right.. i really can't focus today, i'll take another swing at this later, sorry seb_kuzminsky