#linuxcnc-devel Logs

Jul 01 2019

09:44 AM linuxcnc-build: build #5993 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5993
01:30 PM CaptHindsight: "some parts of LinuxCNC have runtime dependencies that are not available in Buster. We'd have to figure out what to do about those parts before we can start shipping Buster debs..."
01:31 PM CaptHindsight: we have been using SID but mostly just testing kernels with LCNC and RTAI
01:31 PM CaptHindsight: haven't run into any dependency issues that were roadblocks
01:48 PM cerna: Not every package available in SID is also in Buster.
01:54 PM CaptHindsight: someone on the forums has been using Buster for at least 6 months, I'll have to find the link
01:58 PM cerna: There actually is no reason why it should not ne do. The hm2_eth would need upgrade, though.
02:00 PM CaptHindsight: I'll have to try running a Meas Ethernet board and see if there are issues
02:01 PM CaptHindsight: Meas/Mesa
02:02 PM cerna: Buster does not come with iptables, I think.
02:07 PM pcw_mesa: buster uses nftables which is supposed to be compatible
02:07 PM CaptHindsight: all the recent RTAI 5.2 work was done on Sid
02:07 PM CaptHindsight: it's working and ready for testers by the way
02:08 PM CaptHindsight: the pci 8255 driver doesn't want to build...
02:09 PM pcw_mesa: something about how it accesses PCI?
02:09 PM pcw_mesa: 32 bit only code?
02:09 PM CaptHindsight: forget the exact issue
02:10 PM pcw_mesa: not sure if anyone is actually using that card
02:11 PM CaptHindsight: builds and runs without it.... he commented it out and it runs now
02:11 PM memfrob: Hello, the RTAI dev has arrived.
02:12 PM CaptHindsight: https://www.ni.com/en-us/support/model.pcie-8255.html
02:12 PM CaptHindsight: is this the 8255^^
02:12 PM pcw_mesa: no
02:13 PM CaptHindsight: https://emergent.unpythonic.net/01165433819 "Do not buy: PCI-8255"
02:13 PM CaptHindsight: Jeffs blog
02:13 PM memfrob: Ah so this is the 8255: http://futurlec.com/PCI8255.shtml
02:16 PM pcw_mesa: Hmm 2 layer board with no bypassing on PCI bridge, looks a bit iffy...
02:16 PM CaptHindsight: yeah a turd
02:17 PM CaptHindsight: Out of Stock anyway
02:17 PM CaptHindsight: probably obsolete
02:18 PM CaptHindsight: i ordered some boards from futurlec a few years ago...
02:18 PM pcw_mesa: I think Intersil/Renasas is the last manufacturer of 8255 chips, we sill use the PLCC versions on ancient crap we sell
02:18 PM CaptHindsight: all I ended up using were adapters from one pinout to another
02:19 PM memfrob: Patch needed for LinuxCNC to build it against new kernel+RTAI: http://dpaste.com/2VWC517
02:20 PM memfrob: andypugh and I have been over this but there's a line splitting issue in LinuxCNC's configure.ac
02:21 PM memfrob: KERNEL_VERS=`$CC -E -dM ${VERSION_FILE} | grep UTS | cut -d '"' -f 2` chops up newer RTAI kernel strings
02:22 PM CaptHindsight: the Tiger 320 looks like a dead part and website
02:22 PM CaptHindsight: http://futurlec.com/Pictures/PCI8255V3b_600.jpg
02:22 PM CaptHindsight: http://futurlec.com/Pictures/PCI8255V3c_600.jpg
03:02 PM CaptHindsight: https://en.wikipedia.org/wiki/Intel_8255
03:02 PM CaptHindsight: been so long
03:03 PM CaptHindsight: I recall stuffing 4+ of these on ISA cards for IO
03:04 PM CaptHindsight: http://map.grauw.nl/resources/ppi/chipsi8255.pdf
03:12 PM seb_kuzminsky: i just pushed a branch named 2.7-buster-package, that lets me build debs on buster
03:12 PM seb_kuzminsky: the debs don't install because they Depend on packages that aren't available in Buster:
03:13 PM seb_kuzminsky: python-gtksourceview2 and python-vte
03:15 PM seb_kuzminsky: i looked into gtksourceview a little bit, but i did not look into vte at all
03:15 PM seb_kuzminsky: i think we have three users of gtksourceview, all inside gladevcp
03:16 PM seb_kuzminsky: there's supposedly a new way to do a similar thing in gtk 3, but i didn't fiddle with it enough to get it to run
03:18 PM memfrob: seb_kuzminsky, I'm running sid and have python-gtksourceview2
03:18 PM memfrob: wait.. how come jessie, sid and stretch have it, but not buster?
03:18 PM memfrob: https://packages.debian.org/search?keywords=python-gtksourceview2
03:18 PM jthornton: yea sid still has python-gtksourceview2
03:19 PM jthornton: https://packages.debian.org/search?keywords=python-gtksourceview2
03:19 PM memfrob: that makes no sense to me at all.
03:19 PM jthornton: lol same link
03:19 PM memfrob: xD
03:19 PM CaptHindsight: Debian distro devs make the call, dare we ask them?
03:19 PM * jthornton goes to finish caulking the siding
03:20 PM CaptHindsight: or just accept "because"
03:21 PM seb_kuzminsky: i'm sure they had a good reason to leave it out of Buster, but i don't know what that reason was
03:21 PM CaptHindsight: esp if there is some way to do whatever required it with gtk3
03:21 PM memfrob: I added a helper function to rtai-config so that the line splitting issue in LinuxCNC mainline is gone
03:22 PM CaptHindsight: ah found the Buster thread https://github.com/machinekit/machinekit/issues/1323
03:23 PM CaptHindsight: was on their ML not this one
03:24 PM CaptHindsight: https://github.com/LinuxCNC/linuxcnc/issues/341
03:27 PM memfrob: it works!
03:30 PM Tom_L: yay!
03:33 PM memfrob: https://github.com/NTULINUX/RTAI/commit/3192818c42d0b520d79649ba6329f6aedbf29d67
03:33 PM memfrob: rtai-config --full-linux-ver is your friend :)
03:39 PM Tom_L: you got them to fix it?
03:40 PM memfrob: who is them?
03:40 PM CaptHindsight: Tom_L: he fixed it
03:40 PM Tom_L: or are you Alec?
03:40 PM memfrob: I'm Alec :)
03:40 PM Tom_L: awesome
03:40 PM Tom_L: :)
03:43 PM Tom_L: that works with stretch?
03:43 PM memfrob: Works with Linux. All Linux with the appropriate dev tools
03:44 PM Tom_L: k
03:44 PM memfrob: There is no debian folder in RTAI so building the deb for that is in your hands
03:44 PM Tom_L: you had to swap out all the math functions right?
03:44 PM memfrob: I integrated musl into the tree like an absolute boss
03:45 PM memfrob: https://github.com/NTULINUX/RTAI/blob/for-next/base/math/GNUmakefile.am
03:46 PM Tom_L: greek to me but i get the jist of what's going on there
03:46 PM memfrob: Makefile git clones musl and builds it, then rtai_math.ko gets linked to it
03:47 PM memfrob: You need an internet connection to compile RTAI but as long as you have one, this method always works.
03:47 PM Tom_L: not many don't nowdays unless it's on the machine itself
04:30 PM memfrob: andypugh, I have math working and a patch for LinuxCNC to build it against the latest RTAI code
04:31 PM memfrob: https://github.com/NTULINUX/RTAI/tree/for-next/linuxcnc_patches
04:31 PM andypugh: Cool
04:31 PM memfrob: Leaving now but just wanted to let you know. Take care!
04:32 PM andypugh: (I am trying to figure out what it is that happens with config.ac and ./configure that strips the trailing quote from line 204 of config.h
04:32 PM memfrob: I added a helper function which takes care of that
04:32 PM memfrob: so it's not hard coded to the running kernel
04:33 PM memfrob: https://github.com/NTULINUX/RTAI/commit/3192818c42d0b520d79649ba6329f6aedbf29d67
04:33 PM andypugh: It’s wierd, as other AC_DEFINE_UNQUOTED entries work fine.
04:33 PM andypugh: C_DEFINE_UNQUOTED([MODULE_EXT], "$MODEXT", [Extension for realtime modules])
04:33 PM andypugh: for example
04:33 PM memfrob: well that's easier to read :P
04:34 PM memfrob: when you have = - _ * X.XY that's when things can break without a lot of quotes
04:34 PM andypugh: Right, so it’s my choice of -RTAI at the end of the kernel version?
04:34 PM memfrob: not necessarily
04:35 PM memfrob: if it was completely empty it might work as-is idk.
04:35 PM memfrob: but linuxcnc should work if -RTAI is set as the name
04:35 PM memfrob: it's bad code if it doesn't
04:35 PM andypugh: Hmm, your patch includes the patch :-)
04:35 PM memfrob: gotta go! take care, best of luck to you my friend!
04:35 PM memfrob: no it's slightly different
04:36 PM andypugh: OK, it will take me some time to study it.
05:26 PM cerna: Am I the only one who finds .patch files in git repository extremely odd?
05:37 PM andypugh: Possibly
06:01 PM memfrob: Hahaha!
06:02 PM memfrob: Basically, instead of the old way of using grep $CC and all that, it makes a call to rtai-config which points to the kernel source directory's .config and then loads it, and spits out the full kernel version string (the one that includes CONFIG_LOCALVERSION)
06:04 PM memfrob: rtai-config: --full-linux-ver: echo "${RTAI_LINUX_VERSION}${CONFIG_LOCALVERSION}" LinuxCNC: RTAI_LINUXVER=`$RTS --full-linux-ver` KERNEL_VERS="${RTAI_LINUXVER}"
06:05 PM memfrob: This method allows you to still compile LinuxCNC against kernel you're not running (because it doesn't use uname -r and uses --full-linux-ver instead)
06:06 PM andypugh: Sounds good to me
06:07 PM memfrob: One down side: this method won't work for old RTAI code
06:07 PM memfrob: but technically the old RTAI code doesn't work anyway because even 3.16.52 has a problem with LinuxCNC as-is
06:07 PM andypugh: Its a patch in your RTAI that is meant to be applied to LinuxCNC.
06:08 PM andypugh: it seems like perhaps there is an argument for conditional compilation to retain the existing (even if broken) situation.
06:08 PM memfrob: well I patched RTAI to include a helper function to LinuxCNC, and I included a patch that tells LinuxCNC's configure.ac to use that helper function
06:09 PM andypugh: And there is _no_ way that could ever get broken :-)
06:09 PM memfrob: The only way the helper function would break is if you deleted the kernel source of the RTAI kernel
06:10 PM memfrob: and if you do that, you can't build linuxcnc anyway because you cant build out-of-tree modules without the source
06:10 PM andypugh: Or tried to build against another RTAI release without your patch.
06:11 PM memfrob: well no previous RTAI release works with linuxcnc except ancient tarballs from the rtai website
06:11 PM andypugh: Granted
06:11 PM andypugh: I was looking optimistically forwards
06:12 PM memfrob: Oh forward wise, there's no reason why it wouldn't work unless you broke something in your kernel tree
06:12 PM andypugh: TRAI v6…. ?
06:12 PM memfrob: if you go into your kernel source and ran `make mrproper` and went straight to building linuxcnc after that, it wouldn't work
06:12 PM andypugh: RTAI, I mean
06:12 PM memfrob: You'd need my patch in RTAI 6
06:12 PM memfrob: (RTAI-side)
06:13 PM memfrob: --full-linux-ver is not a mainline RTAI function
06:13 PM memfrob: and never will be
06:13 PM andypugh: Yes, that’s my point.
06:13 PM memfrob: but I'm going to keep RTAI updated
06:14 PM andypugh: OK, it’s good to have that commitment. I make no such comitment for LinuxCNC.
06:14 PM andypugh: Who knows, I might get a social life or something.
06:14 PM memfrob: it's not much work to keep it updated from this point forward
06:14 PM memfrob: the big jump was from 4 to 5 due to all the kernel 4.X work
06:14 PM andypugh: Why does your patch disable pci_8255?
06:15 PM memfrob: because that's the only card that doesn't build
06:15 PM andypugh: OK.
06:15 PM memfrob: maintaining RTAI is easy once it's at this point
06:15 PM andypugh: But both users might be upset by that?
06:16 PM memfrob: 8255 is apparently crap anyway that nobody cares about
06:16 PM CaptHindsight: they can use them with an old RTAI kernel
06:16 PM CaptHindsight: PCI bus
06:17 PM CaptHindsight: not available on lots of new hardware anyway
06:17 PM memfrob: which would then need a fix for LinuxCNC's configure file because the kernel string would break again
06:18 PM memfrob: 8255 is essentially broken if --full-linux-ver doesn't exist
06:20 PM memfrob: wait hold on.. I messed that up. The 8255 driver is broken if --full-linux-ver exists, LinuxCNC is broken if you're using RTAI 4 or newer, you must go all the way back to version 3
06:20 PM andypugh: Right
06:22 PM memfrob: andypugh, how difficult are these errors to fix anyway? http://dpaste.com/19EZJFW Ignore the first one, that's already fixed.
06:24 PM andypugh: They look easy. They might not be.
06:25 PM andypugh: The test for *cfg == ‘/0’ could presumably be ==0 ?
06:29 PM memfrob: No idea.
06:30 PM andypugh: Hmm, google suggests that the problem is pointer dereferencing.
06:30 PM andypugh: The others look like a macro clash.
06:31 PM memfrob: Ignore the first 22 lines
06:31 PM memfrob: Commenting out #include <asm/uaccess.h> in src/rtapi/rtai_rtapi.c solves the top one.
06:32 PM memfrob: that's already included in the patch (it's an old paste from before)
06:32 PM andypugh: The other seems to be that kernel.h deifnes READ = 0 whereas pci_8255 uses it as a function name
06:33 PM memfrob: so it just needs to be more unique?
06:33 PM memfrob: change it to READ_LINUXCNC ?
06:33 PM andypugh: I think that a find.replace in pci_8255 from READ to read might well be enough.
06:33 PM andypugh: or read_8255
06:34 PM andypugh: Like in the hostmot2 driver everything is hm2_read and hm2_write
06:34 PM memfrob: so 8255_read
06:35 PM andypugh: Can a function name start with a numeral?
06:35 PM memfrob: (so it matches my OCD)
06:35 PM andypugh: pci8255_read would work, I imagine.
06:35 PM memfrob: but then they won't match the hm2 driver, hm2 driver should be read_hm2 then :P
06:35 PM andypugh: Is that a test you can easily do?
06:36 PM andypugh: Hmm, no, I put the module first then function, just like hm2
06:36 PM memfrob: read_8255 is putting the function first
06:37 PM andypugh: Which is why I suggested pci8255_read
06:37 PM memfrob: Yes that's good.
06:37 PM memfrob: plus it sounds really low-level and cool
06:38 PM memfrob: using READ is just boring
06:38 PM andypugh: Currenlty my build is stalled at “checking for adeos... ./configure: eval: line 7522: syntax error near unexpected token `(‘”
06:39 PM memfrob: checking for adeos... not found
06:40 PM memfrob: Oh yeah, another thing with the configure line. Linuxcnc doesn't work if fifos sem and shm are modules, they have to be built-in now (into rtai_sched.ko) but it checks for them anyway: checking for rtai_fifos... not found
06:41 PM andypugh: http://dpaste.com/09108G1
06:41 PM andypugh: I suspect I need to do some stuff….
06:41 PM memfrob: cd RTAI && git pull ; re-build and reinstall it
06:42 PM memfrob: and make sure you apply the linuxcnc patch inside the RTAI tree
06:42 PM andypugh: install! That’s the thing i missed
06:42 PM memfrob: heh!
06:43 PM andypugh: Much better :-)
06:47 PM andypugh: It looks like LinuxCNC is going to build
06:47 PM andypugh: Yes, it finsihed
06:48 PM jthornton: yippie
06:49 PM andypugh: Hmm: insmod: ERROR: could not insert module /home/andypugh/linuxcnc-dev/rtlib/rtapi.ko: Unknown symbol in module
06:49 PM andypugh: A puzzle for tomorrow, I suspect.
06:50 PM memfrob: dmesg it really quick
06:51 PM andypugh: http://dpaste.com/3KZ6BQP
06:51 PM memfrob: yes i know that one
06:52 PM memfrob: i re-worked the RTAI config defaults but you have to make menuconfig ; i did
06:52 PM memfrob: * i didn
06:52 PM memfrob: OMG
06:52 PM memfrob: i didn't add those yet to RTAI's configure line
06:52 PM memfrob: *file
06:53 PM memfrob: linuxcnc changed what should and shouldn't be a module vs. built-in with RTAI
06:53 PM memfrob: so to fix it, you need to run make menuconfig and make sure FIFOs, SEM and SHM are enabled (Y)
06:54 PM memfrob: I'll add those as defaults to RTAI's configure as well
06:55 PM memfrob: wait i already did..
06:55 PM memfrob: In RTAI you should probably run a make distclean && ./autogen.sh again (for tomorrow if you like)
06:56 PM memfrob: your RTAI config was generated before I added in the defaults for linuxcnc
06:56 PM memfrob: This is what I meant by: <memfrob> Oh yeah, another thing with the configure line. Linuxcnc doesn't work if fifos sem and shm are modules, they have to be built-in now (into rtai_sched.ko) but it checks for them anyway: checking for rtai_fifos... not found
07:00 PM andypugh: Right, I see
07:00 PM andypugh: I fixed pci8255..
07:00 PM memfrob: oh nice!
07:06 PM andypugh: compiling RTAI is giving me a _lot_ of warnings
07:08 PM andypugh: https://paste.ubuntu.com/p/JVzdBtrm6F/
07:08 PM memfrob: Ignore the many undefined symbol warnings above.
07:09 PM andypugh: OK…
07:09 PM memfrob: Hahaha, I know, it's because those symbols don't get added until line 940 of your post
07:09 PM memfrob: mainline RTAI is the same way, Paolo said to ignore them
07:10 PM Tom_L: no way to declare them external or such?
07:10 PM Tom_L: so they don't show up
07:11 PM memfrob: https://github.com/NTULINUX/RTAI/blob/for-next/base/math/export_musl.h
07:11 PM memfrob: If you know of a way to do that?
07:11 PM Tom_L: not me :)
07:11 PM Tom_L: i've done that in the past with other languages
07:12 PM Tom_L: if i knew something was gonna be there
07:12 PM memfrob: I don't think you have extern EXPORT_SYMBOL it'd be too easy
07:12 PM memfrob: *you can have
07:14 PM Tom_L: https://www.quora.com/What-is-the-difference-between-extern-and-EXPORT_SYMBOL-in-Linux-kernel-codes
07:18 PM memfrob: They're exported symbols which are undefined because they're defined in musl, but the linking happens after the module is built
07:18 PM memfrob: you can't link a pre-existing module
07:18 PM Tom_L: yeah i figured it would be too easy
07:25 PM andypugh: OK, I am still getting the “[102247.151669] rtapi: Unknown symbol rtf_get (err 0)” etc errors.
07:25 PM memfrob: the same ones??
07:25 PM andypugh: I will have another go tomorrow, starting from scratch.
07:25 PM memfrob: ok, take care andypugh
07:25 PM andypugh: Do I need to rebuild the kernel?
07:25 PM memfrob: no, this is all has to do with rtai_sched.ko
07:26 PM memfrob: fifos sem and shm.ko should not exist, they should all be inside rtai_sched.ko
07:27 PM andypugh: OK.
07:27 PM andypugh: Anyway, goodnight for now
07:27 PM memfrob: http://dpaste.com/3AJXCVT
07:28 PM memfrob: http://dpaste.com/04A7KFG
07:28 PM memfrob: etc etc
07:29 PM memfrob: big thanks to seb_kuzminsky for teaching me about objdump!
07:35 PM Tom_L: shows the symbols in an obj file?
07:36 PM memfrob: yes
07:38 PM Tom_L: do those happen at compile time or link time?
07:38 PM Tom_L: when the symbol table is generated
07:39 PM Tom_L: i suppose if it's obj it would be at compile time
07:39 PM memfrob: yes
07:39 PM memfrob: compile
07:39 PM memfrob: link time would maybe add more symbols though to it
07:39 PM memfrob: so technically both
07:47 PM memfrob: i'm pretty sure anyway
07:47 PM Tom_L: i don't know enough to argue the point either :)
07:49 PM Tom_L: i thought either C or the linker would generate a symbol file automatically
07:49 PM Tom_L: maybe not
07:50 PM Tom_L: i don't use gcc much
07:51 PM Tom_L: maybe those are intended for the gdb debugger?
07:52 PM Tom_L: the -g flag
07:52 PM memfrob: i think what it is.. you cannot add symbols at link time, only the _definitions_ of the symbols
07:53 PM Tom_L: https://stackoverflow.com/questions/2577068/what-is-symbol-table-and-how-is-it-integrated-into-the-executable
07:53 PM memfrob: so what you think is a symbol at link time, is really just what that symbol means
07:53 PM Tom_L: that says normal ones are still included in the ELF files
07:53 PM Tom_L: the -g ones are additional ones for debugging i think
07:53 PM memfrob: what separates an abnormal symbol from a normal one? :3
07:54 PM Tom_L: hah
07:54 PM Tom_L: beats me
07:57 PM Tom_L: the subset are linking symbols
07:57 PM Tom_L: the -g probably includes all vars etc
08:07 PM memfrob: -g is a CFLAG for debugging
08:08 PM memfrob: -g3 is max, -g2 is the default i believe
08:09 PM memfrob: (that is, if -g is set)