Back
[00:10:33] <memleak> jepler, nobody is familiar with the proc code??
[00:10:50] <memleak> who wrote it.. *checks headers*
[00:11:46] <memleak> John Kasunich and Paul Corner, two names i never seen before.
[01:38:07] <archivist> you must not be reading the mailing lists then, JMK is still watching and writing messages and explanations
[01:38:42] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 664f292 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix error when no firmware has been downloaded * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=664f292
[01:53:52] <memleak> 3.4.103 working now too :D
[02:41:20] <memleak> why math modules for rtai and linuxcnc hang with gcc 4.8.3 without -msse2 specified however 4.6.4 works just fine?..
[02:41:51] <memleak> no compiling error, it will simply freeze.
[02:42:44] <memleak> -mmmx -mavx -m<insert any valid 3 letter acronym here> will prevent the hang issue.
[02:47:08] <memleak> odd.. with -msse2 set in RTAI the hang goes away in linuxcnc with default cflags specified in makefile
[02:48:13] <memleak> ah undefined symbol: sincos.. that thing again.. -_-
[03:27:19] <alex_joni> cradek: no problem with that
[03:27:39] <alex_joni> (I wonder how many days ago that was..)
[07:04:13] <jepler> memleak: yes, all these problems have been mentioned before, and nobody has been systematic enough to figure out what is going on
[07:05:36] <jepler> e.g.,
http://mid.gmane.org/20111222160214.3d930896%40milhouse
[07:19:01] <jepler> memleak: -no-msse changes the ABI on x86_64 for any function that accepts or returns FP arguments
[07:19:56] <jepler> memleak: so for example 'void f(double d)' will pass d on the stack with -mno-sse, instead of in %xmm0 as the x86-64 ABI calls for
[07:20:25] <jepler> and 'double h(void)' is just an error, because there's no register to return a FP value in
[07:21:37] <jepler> memleak: as for sincos, gcc is cunning. it will notice the special form of a function like this, and turn its body into a call to the builtin function 'sincos':
[07:21:41] <jepler> void sincos(double theta, double *sin_out, double *cos_out) {
[07:21:43] <jepler> *cos_out = cos(theta);
[07:21:46] <jepler> *sin_out = sin(theta);
[07:21:48] <jepler> }
[07:22:18] <jepler> (in the gcc verison I tried today,) -mno-builtin-sincos has no effect on this transformation but either -mno-builtin-sin or -mno-builtin-cos stop it
[07:27:37] <jepler> -msse -mno-sse2 is a dubious combination. In this configuration, the %xmm0 architectural register is available and you can do 8-byte loads and stores from it, but you can't do any arithmetic on doubles
[07:28:30] <jepler> so extern double g; double f(double d) { g=d+d; } compiles into a store of xmm0 to stack, followed by x87 instructions
[07:30:55] <jepler> does rtai even set up x87 state for 64-bit land?
[07:31:10] <jepler> anyway, it's my belief that -msse -msse2 are the "right" flags for x86_64 in kernel space
[07:32:12] <jepler> but ultimately that rtai and linuxcnc had better agree, which means rtai has to put accurate cflags in its configuration file so that we can remove all our danged workarounds that we have accreted over the years
[09:56:37] <seb_kuzminsky> morning folks
[09:56:48] <seb_kuzminsky> i've returned from the land of the hippies
[09:56:55] <seb_kuzminsky> aka planet bluegrass
[09:57:23] <seb_kuzminsky> and now there's... freebsd support? anonymous hal nets? rtai on modern kernels?
[09:57:26] <seb_kuzminsky> you guys dont sleep
[10:06:52] <cradek> I used my lathe to drill a hole in something
[10:06:55] <cradek> does that count?
[10:09:03] <skunkworks_> yes it does!
[10:10:00] <cradek> you're generous
[10:17:52] <seb_kuzminsky> jepler: uspace: make non-portable harden_rt conditional (
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=dc0b626)
[10:18:07] <seb_kuzminsky> did you mean to add a "return -EPERM" after the "return 0"?
[10:35:22] <seb_kuzminsky> jepler: "uspace: make libudev optional" seems to be confused about udev and userspace pci... udev is just hotplug events, right?
[10:35:34] <seb_kuzminsky> nothing directly to do with userspace pci access
[10:36:42] <seb_kuzminsky> very cool branch, btw
[10:49:01] <jepler> seb_kuzminsky: libudev is used to enumerate pci devices
[10:50:18] <jepler> seb_kuzminsky: and yeah, that -EPERM Is wrong
[10:52:24] <jepler> seb_kuzminsky: libudev enumerates PCI devices, and then access to files in /sys is used to actually "do" userspace access.
[10:52:32] <jepler> seb_kuzminsky: both of those parts are missing in debian kfreebsd
[11:05:36] <memleak> jepler, its interesting how much easier it is to compile RTAI + linuxcnc with gcc 4.6.4 compared to 4.8.3, also if you believe accurate IEEE compliant CFLAGS in rtai would help fix the issue i suppose i could work more on that.
[11:10:22] <memleak> who doesnt want udev in the first place? is device-mapper catching on or something?
[11:11:32] <memleak> ah mdev sorry
[11:20:47] <memleak> jepler, default on x86_64 compiler, if -mfpmath=x87 is not set, it uses sse (32-bit x87 is default)
[11:38:33] <jepler> memleak: sse2
[11:38:42] <jepler> but yes, using sse registers
[11:41:13] <jepler> seb_kuzminsky: (welcome back, I'm jealous if you were travelling and doing musical stuff)
[12:08:09] <memleak> closest im getting so far is -mhard-float -msse -mfpmath=387 -mieee-fp for RTAI CFLAGS
[12:09:47] <cradek> we use sincos in about 10 places. if that is what causes the most pain (for whatever reason), we could just remove it.
[12:10:30] <memleak> that would be absolutely lovely!!!!!!!
[12:11:02] <cradek> (unless sincos is just the canary that tells us we've got deeper troubles)
[12:11:09] <memleak> i just went through about 30 CFLAGS last night, and another 15 this morning, gcc 4.8.3 absolutely hates linuxcnc and RTAI
[12:12:34] <memleak> and its not the canary, sincos has 6 undefined references in modules, those are the only ones
[12:12:44] <memleak> if there were more, the linker would complain
[12:13:02] <cradek> well by canary, I mean something like "all the FP code is possibly miscompiled"
[12:13:26] <cradek> we've absolutely had miscompiled code recently, due to compiler bugs
[12:13:42] <cradek> it makes me nervous when switching compiler versions make everything go wonky
[12:13:44] <memleak> ah well gcc 4.8.3 has a bug then
[12:13:51] <cradek> my faith in gcc is a bit lower than usual
[12:14:05] <memleak> maybe i should try clang?
[12:15:20] <memleak> -mieee-fp + no dangerous math flags should not miscompile under any circumstances unless a bug exists within GCC and the mere fact everything works fine with 4.6.4 confirms this
[12:15:49] <memleak> maybe the real fix is a configure check for gcc 4.7+ and if so, crap out.
[12:16:56] <memleak> thats when the bug was introduced. i believe 4.7.0
[12:17:07] <memleak> if not 4.7.2
[12:51:56] <memleak> what just hit me: 32-bit there is never a single problem with sincos, only 64.. what if we compile linuxcnc and rtai the same way as if it were on a 32-bit system?
[12:52:07] <memleak> -msse isnt even specified in RTAI for 32-bit
[12:52:26] <memleak> perhaps even -m32 and generate 32-bit code..
[13:10:22] <memleak> ah i get that sse requested but no return error
[13:17:06] <memleak> ok gcc 4.7+ will not work regardless of CFLAGS used and i know this because i just went through the entire gcc docs and flipped everything from math related, sse, 387, align doubles, wide doubles, frame pointers, everything, so im going to switch my focus to 3.10 and 3.14 support
[13:17:54] <memleak> note that this problem only exists on 64-bit so if you're going to use 64, use gcc 4.6 and it will be running with ease.
[13:24:11] <jepler> memleak: debian jessie builds kernel 3.16 with gcc 4.8, so we'd have to make it work
[13:28:31] <memleak> jepler, you're on your own now then :P
[13:29:58] <jepler> did you try building sincos.c with -fno-builtin-sin -fno-builtin-cos ?
[13:35:31] <memleak> i didnt notice those in the docs, ill give it a shot, thanks
[13:37:01] <jepler> or maybe -ffreestanding
[13:37:34] <memleak> ok thanks!
[13:38:21] <jepler> with respect to sincos particularly, here's why it's different from 32-bit to 64-bit: when the 'sincos pattern' is recognized by gcc, and -fpmath=387, it is turned into a fsincos instruction
[13:38:28] <jepler> with fpmath=sse, it's turned into a call to sincos
[13:38:44] <jepler> -ffreestanding, -fno-builtin-sin, -fno-builtin-cos all inhibit this optimization
[13:40:07] <memleak> ah! that makes a lot of sense now
[13:40:09] <jepler> -mfpmath=387 or -mfpmath=both
[13:40:23] <memleak> i forced -mfpmath=387 and still no change however
[13:41:39] <jepler> most things are not gcc bugs and most things have explanations
[13:41:43] <jepler> we have to believe that or we'd go mad
[13:41:47] <jepler> bbl
[13:44:06] <memleak> :D
[14:49:00] <Markus_> good evening everyone.first time here. having some troubles openening my g-code in emc2. getting the message "unbekannter Befehl im O-Wort" (unknown command in O-Word). Can't find any command which is using an "O"
[14:51:38] <cradek> perhaps open it in an editor and search for o and O?
[14:51:59] <cradek> or pastebin your gcode
[14:54:22] <Markus_> can't believe it. got it figured out. its been a very long way for me to build the hardware of my mill (stepper motor attachmend and electronics), get emc running. Now for the first time I can actually see the milling. Its like if I had won a jackpot.
[14:55:19] <Markus_> will try it on the machine now. will be back with further good news hopefully. So happy
[15:01:25] <jepler> seb_kuzminsky: (anyway, it doesn't build on freebsd, just debian kfreebsd. I ragequit before I could get it to even finish configure on freebsd 9)
[15:23:45] <Markus_> no success. machine doesn't even react on manual movements (using arrows on keyboard). Have checke all cable connection. will try to figgure it out tomarrow. good night
[16:59:38] <Roguish> hello all. how can I do a 'show all' for hal during a running session?
[16:59:54] <Roguish> and capture the output?
[17:00:20] <jepler> open a terminal, . scripts/rip-environment if appropriate, halcmd show all > somefile.txt
[17:03:35] <Roguish> thanks jepler. that's just too easy.
[17:22:16] <PCW> Around?
[17:24:43] <jepler> PCW: what's up?
[17:26:20] <PCW> sorry wrong window
[17:26:50] <PCW> looking for micges (encoder bug)
[17:27:19] <PCW> (though not as bad as it first seemed)
[17:27:32] <micges-dev> PCW: I'm here
[17:27:57] <PCW> minor bug in encoder sample frequency pin
[17:28:25] <PCW> Gene found this
[17:29:47] <micges-dev> PCW: forum?
[17:30:01] <PCW> the sample frequency displayed doesnt account for the magic divide by one case (so the default non muxed sample frequency shows as 8136 Hz)
[17:30:57] <micges-dev> ok
[17:31:33] <PCW> I was worried that it was actually running at 8KHz but its just not shown correctly
[17:32:05] <micges-dev> so it writes correctly but hal pin is wrong?
[17:32:14] <PCW> Yes
[17:33:52] <PCW> its because of the way the hardware works, divide by 1 is a special case with the MSb or the divisor set
[17:33:54] <PCW> (but you cannot figure out the frequency from the divisor the normal way in this case)
[17:35:20] <PCW> (you would never see this on muxed encoders since divide by one is way too fast for the mux rate)
[17:37:25] <jepler> PCW: this is nothing to do with NaN velocity output, right?
[17:37:45] <PCW> No not related (and cosmetic only)
[17:38:43] <micges-dev> PCW: ah I see it
[17:39:42] <PCW> the divide by one case needs to be handled differently
[17:39:44] <micges-dev> I'll fix it later, now I'm on generic kernel
[17:40:08] <PCW> OK
[17:40:38] <micges-dev> iirc I dondivide by one
[17:41:05] <micges-dev> sorry
[17:41:12] <PCW> Ahh this reminds me did you look at the extra WD write packet on hm2_eth?
[17:42:31] <micges-dev> not yet
[17:42:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master c283ee5 06linuxcnc 10src/configure.in 10src/rtapi/rtapi_pci.cc uspace: make libudev optional * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c283ee5
[17:42:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master f1ffa5d 06linuxcnc 10(17 files in 8 dirs) Don't use non-portable integer types like __u32 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f1ffa5d
[17:42:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4d819cc 06linuxcnc 10src/rtapi/rtapi_uspace.hh uspace: ensure declaration of pthread_t is available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d819cc
[17:42:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 2498eff 06linuxcnc 10src/rtapi/rtapi.h 10src/rtapi/uspace_common.h 10src/rtapi/uspace_ulapi.c Get rid of indirect inclusion of rtapi_errno.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2498eff
[17:42:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 7e720eb 06linuxcnc 10(6 files in 4 dirs) Don't use <linux/*.h>, <asm/*.h> blindly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e720eb
[17:42:47] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 68f8f09 06linuxcnc 10src/emc/motion/dbuf.c 10src/hal/drivers/mesa-hostmot2/bitfile.c Don't use errno constants that aren't portable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=68f8f09
[17:42:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 79e7f3b 06linuxcnc 10(9 files in 5 dirs) Drop support for kernels below 2.6.14 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79e7f3b
[17:42:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 5089521 06linuxcnc 10src/libnml/os_intf/_sem.c Avoid printf error due to size of semaphore key type * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5089521
[17:42:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 2cc8534 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc Don't use nonportable linux socket semantics * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2cc8534
[17:45:23] <PCW> surprisingly enough tcpdump works pretty well for finding network oddities even while linuxcnc is running
[17:45:49] <PCW> (oddities on the Rt Ethernet link)
[17:47:15] <micges-dev> any other problems besides WD ?
[17:48:06] <memleak> jepler, i think specifiying -ffreestanding -fno-builtin{sin,cos} in both RTAI and linuxcnc fixed the problem..
[17:48:18] <micges-dev> brb
[17:50:27] <jepler> memleak: oh hey, sounds like good news
[17:52:43] <memleak> yeah it works with kernel 3.10 w/ GCC 4.8.3 (proc code removed from linuxcnc)
[17:56:16] <PCW> micges-dev: only other bug Ive noticed is a naming problem on the 7I76E (double dots)
[17:56:18] <PCW> Must be up close to 100 days now at 2 KHz (mostly ubc3-7i80 but last few weeks master/uspace)
[17:58:11] <memleak> thanks a bunch!!
[18:00:16] <micges> PCW: yeah I remember that one
[18:00:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 3487af9 06linuxcnc 10src/configure.in configure: fix --enable-check-runtime-deps * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3487af9
[18:39:44] <memleak> is any of the proc code in linuxcnc used for anything not related to debugging / printing output?
[18:40:11] <memleak> im digging through the proc code and all i really see are proc_print macros
[18:40:35] <jepler> memleak: yeah just debugging afaik
[18:40:42] <jepler> and debugging that I haven't used in a long, long time
[18:40:51] <jepler> .. personally
[18:41:14] <jepler> so a conditional #if kernel version .. disable proc entirely .. #endif until somebody fixes it for real is a viable option imo
[18:42:17] <jepler> seb_kuzminsky: thanks for fixing my autoconf
[18:42:42] <jepler> seb_kuzminsky: I know you glanced at some of those commits ^^ when they were on jepler/kfreebsd, but I think these are master-worthy. I'd love your feedback if you've got time.
[18:42:46] <jepler> will read back
[18:46:13] <memleak> https://github.com/NTULINUX/RTAI/commit/10a1b48d575ede770f0c5e966b9346ff5bfe6b07 (all of necessary /proc changes in RTAI in one commit)
[18:46:50] <jepler> memleak: ah you're talking rtai's /proc stuff
[18:46:54] <jepler> memleak: I was thinking of linuxcnc's.
[18:47:12] <memleak> jepler, no i was talking about linuxcnc
[18:47:29] <memleak> im saying that commit link i just posted is the one that breaks linuxcnnc's proc code
[18:48:12] <memleak> (which doesnt affect the behavior of linuxcnc which is awesome)
[18:48:40] <jepler> memleak: are you saying linuxcnc uses RTAI APIs to /proc, not kernel APIs?
[18:48:48] <memleak> correct.
[18:49:08] <memleak> if it used kernel APIs this issue wouldnt exist.
[18:49:30] <jepler> that's weird, I'd have sworn that the /proc stuff was portable to rtl
[18:49:31] <jepler> rtapi/rtl_rtapi.c:#include "rtapi_proc.h" /* proc filesystem decls
[18:49:56] <memleak> and if it did use kernel APIs, 3.10+ preempt rt kernel usage when compiling linuxcnc it would fail.
[18:50:07] <jepler> nah it's just turned off there
[18:50:11] <memleak> oh..
[18:51:17] <jepler> the rt-preempt stuff is pure userspace, so it can't create /proc entries very well
[18:51:30] <memleak> ah right
[18:52:30] <jepler> and shamelessly ripped from rtai_proc_fs.h, part of the RTAI
[18:52:30] <jepler> project. See
http://www.rtai.org for more details.
[18:52:34] <jepler> /* proc print macros - Contributed by: Erwin Rol (erwin@muffin.org)
[18:52:38] <jepler> err pardon the bad paste
[18:52:42] <jepler> that's what it says in rtapi/procfs_macros.h
[18:53:53] <jepler> did linux's own /proc interface change in 3.10?
[18:54:24] <memleak> yes
[18:54:47] <memleak> thats why paolo adopted xenomai in the first place
[18:55:26] <memleak> xenomai was ahead and paolo wanted 3.10
[18:55:59] <memleak> all the new proc code in rtai came from there
[18:59:22] <jepler> this ought to do it until someone steps up
http://emergent.unpythonic.net/files/sandbox/0001-rtapi-disable-proc-for-kernel-3.10.patch
[18:59:41] <jepler> hah: It is unlikely that the following implimentaion will work on a 2.0
[18:59:44] <jepler> ... kernel
[18:59:50] <jepler> (sic)
[19:32:16] <memleak> how to testcase for gcc 4.7 and apply -ffreestanding -fno-builtin-sincos to makefile?
[19:34:10] <jepler> memleak: have rtai-config return it in --module-cflags
[19:34:40] <jepler> and optionally screw with EXTRA_CFLAGS in linuxcnc's Makefile
[19:35:22] <jepler> we unconditionally strip -ffast-math, unconditionally specify -fno-unsafe-math-optimizations and conditionally specify -msse, it looks like
[19:35:33] <memleak> yes i saw that
[19:35:35] <jepler> (conditioned on being x86_64 with rtai 3.x)
[19:35:59] <memleak> in rtai-config RTAI_KERNEL_CFLAGS show freestanding etc
[19:36:21] <jepler> configure linuxcnc and have a look at what you got for RTFLAGS
[19:36:36] <jepler> but RTAI_KERNEL_CFLAGS sounds like what should come out in rtai-config --module-cflags
[19:36:43] <memleak> ah ok
[19:38:24] <jepler> RTFLAGS in Makefile.inc
[19:39:36] <KGB-linuxcnc> 03Chris Morley 052.6 b38e98c 06linuxcnc 10configs/sim/axis/axis.ini 10docs/src/config/ini_config.txt 10src/emc/usr_intf/axis/scripts/axis.py axis -add ability to set default spindle speed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b38e98c
[19:43:47] <memleak> ok thanks ill look that over
[19:45:46] <jepler> bbl
[20:14:52] <seb_kuzminsky> thanks cmorley
[20:15:45] <cmorley> you bet - sorry I woulda merged to master but there is a conflict that I don't know enough about...
[20:18:00] <seb_kuzminsky> ok, i'll look at it later :-)
[20:59:42] <jepler> seb_kuzminsky: the conflict is VERSION; I assume take master's side
[21:00:54] <KGB-linuxcnc> 03Jeff Epler 05master 4a6cb8a 06linuxcnc 10debian/configure 10docs/src/config/ini_config.txt 10docs/src/hal/comp.txt 10src/emc/usr_intf/axis/scripts/axis.py Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a6cb8a
[21:42:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1ba6b02 06linuxcnc 10docs/src/config/ini_config_fr.txt Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1ba6b02
[21:43:14] <seb_kuzminsky> jepler: yep, & thanks
[21:43:25] <seb_kuzminsky> & here
[21:43:29] <seb_kuzminsky> 's one more
[21:43:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master f8b217d 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f8b217d
[22:59:22] <cradek> cmorley: about your forum post about gladevcp: I think we fixed this on the debian 7 install? we just built the necessary glade. do you still know of a problem?
[23:34:28] <cmorley> no. sorry I didn't realize this had been done. I'm still using 10.04 mostly and 12.04 mint sometimes - way behind :)