#linuxcnc-devel Logs

Jul 07 2019

11:23 AM Tom_itx is now known as Tom_L
03:46 PM memfrob: andypugh isn't here but he sent me a pull request 30 mins ago.
03:47 PM memfrob: I missed him?
05:39 PM memfrob: I changed the assembly section of the RTAU scheduling code to use the current assembly in the latest linux kernel and it's running even better now.
05:39 PM memfrob: push > mov
05:40 PM memfrob: The original code was from kernel 2.6.20
06:01 PM Centurion_Dan: memfrob: is their much assembly in that RTAI? I'm mindful of portability - particularly for ppc64(el) as I happen to have a TalosII (IBM Power9 based) system
06:02 PM Centurion_Dan: which is used to build ppc64el and hopefully soon ppc64 (big endian) too.
06:03 PM memfrob: ASM isn't your problem with RTAI haha
06:04 PM memfrob: ppc64, ARM, all architectures are unmaintained in mainline except x86, if you want anything not-x86 based, you need to back to 1997.
06:05 PM memfrob: There isn't much assembly though, no.
06:06 PM memfrob: http://svn.savannah.gnu.org/viewvc/rtai/vulcano/base/arch/arm/patches/
06:08 PM memfrob: If you want other architectures, stick with preempt_rt if you can (or xenomai, haven't tried it, won't bother)
06:15 PM memfrob: PPC and other arch support has been removed in RTAI, ARM is the only one non-x86 left, but since RTAI has dropped support for kernels < 3.2 -- it won't compile as-is
06:17 PM memfrob: Your best bet is using Debian Etch (4.0) (with obviously very old hardware) if you want non-x86
06:29 PM memfrob: RTAI 3.8.X and maybe 3.9.X was the last release that had any of that working.
06:40 PM Centurion_Dan: bugger... I was planning on using an espressobin (arm64) for linxcnc. I guess I'll have to stick to rt_preemp kernels instead...
06:40 PM memfrob: Indeed.
06:42 PM memfrob: If latency is within your requirements, it shouldn't matter anyway. If you're using POSIX threads over ethernet (hm2_eth) then you don't need the same real-time constraints as when using parport
06:47 PM memfrob: andypugh, my man!
06:48 PM andypugh: Hi
06:48 PM memfrob: how are you?
06:48 PM andypugh: Spent all of today driving, not really good for anything
06:48 PM andypugh: Installed Buster yet?
06:48 PM memfrob: Me?
06:49 PM andypugh: That was my plan for when I got home, bot, well, I didn’t.
06:49 PM memfrob: I don't run Buster on my hardware, using sid.
06:50 PM memfrob: stable is old, testing is out of date, sid is current stable. :)
06:51 PM andypugh: I think that the offical Buster ISO came out yesterday?
06:51 PM memfrob: I have no idea.
06:52 PM andypugh: https://lists.debian.org/debian-announce/2019/msg00003.html
06:53 PM andypugh: So Buster is the latest, released, LTS version
06:54 PM memfrob: system crashed testing out things in rtai
06:54 PM memfrob: if you said anything, i missed it
06:55 PM memfrob: don't crash this time..
06:55 PM memfrob: rtai_hal: version magic '4.14.131-RTAI SMP preempt mod_unload ' should be '4.14.132-rtai+ SMP preempt mod_unload '
06:55 PM memfrob: that's odd
06:56 PM andypugh: I thought you were on 132?
06:56 PM memfrob: I was, debian is in a weird state lol
06:59 PM andypugh: Seems that you might be running a 131 RTAI on a 132 kernel?
06:59 PM memfrob: i ran make clean, i did rm -rf /boot/*4.14* && rm -rf /lib/modules/*4.14* and doing this again
07:00 PM andypugh: Might have to clean out usr/realtime too?
07:00 PM memfrob: i did before i installed it again
07:00 PM memfrob: i was probably tired and messed something up
07:00 PM andypugh: Well, You almost certainly make fewer config mistakes than I do, so I await your conclusions. :-)
07:01 PM memfrob: how does debian know that i recompiled the kernel 7 times?
07:01 PM memfrob: dpkg-deb: building package 'linux-image-4.14.132-rtai' in '../linux-image-4.14.132-rtai_4.14.132-rtai-7_amd64.deb'
07:02 PM memfrob: ohhh that's why. /usr/src/linux is 4.14.131
07:03 PM andypugh: the -7 might be from debaian/changelog ?
07:03 PM memfrob: oh inside the kernel tree
07:03 PM memfrob: yep, thank you. thought it was juju.
07:07 PM memfrob: andypugh, when you have a chance, some day, any day, can you try my no-calibration branch out in RTAI?
07:08 PM andypugh: I can try. What does it do different?
07:08 PM andypugh: (ie, what’s it for?)
07:08 PM memfrob: I'm curious to see if it will run/work well on the same hardware that had issues with RTAI in the past. It removes the usermode check and latency calibration and makes RTAI perform like it did over the last decade.
07:09 PM memfrob: there's no self calibration or anything, it's the simple approach that always "just worked"
07:11 PM memfrob: oh for the kernel packages, to avoid this problem i just encountered, i think it'd be best for the .deb to have a command like this in it: if [ ! -d /usr/src/linux ] ; then ln -sfv /usr/src/linux-headers-${KERNEL_VERSION} /usr/src/linux ; fi
07:12 PM memfrob: basically, install the kernel headers not only to /usr/src/linux-headers-4.14.132-rtai but also symlink it to /usr/src/linux
07:13 PM andypugh: Do packages normally look in /usr/src at all?
07:13 PM memfrob: RTAI does
07:13 PM andypugh: Oh, OK.
07:14 PM memfrob: I can change it to suit debian but then it won't be universal. perhaps I can add if statements to it though versus changing the way the kernel gets packaged
07:14 PM memfrob: either way, the user shouldn't run into the problem i just did.
07:15 PM memfrob: oh it's actually already there in autogen.sh but it needs the same logic in configure.ac
07:15 PM memfrob: so nevermind everything i just said about /usr/src, i'll just make the two the same
07:16 PM memfrob: if people want to run into a potential issue, they're happy to play with --linux-dir on the RTAI configure line
07:16 PM memfrob: brb new kernel
07:59 PM memfrob: ok I fixed the overly complicated logic with RTAI_LINUX_DIR
08:00 PM memfrob: People who use double negatives in their code should be shot.
08:01 PM memfrob: https://github.com/NTULINUX/RTAI/commit/15c9b369dda10d5d58ca02cdce7f1b09b8eb9299
09:32 PM memfrob: thats enough RTAI for today, take care everyone!