#linuxcnc-devel Logs

Sep 12 2017

12:43 AM memfrob: Hey everyone, I've been working on solving countless issues within IPIPE (the RTAI kernel patch) and have finally been able to have all the debugging options (including boot time self tests such as link sorting, ring buffer, kernel tracing etc) co-exist with real-time.
12:47 AM memfrob: I've been cherry-picking commits from git.kernel.org and solved all the long-term issues, so practically all the options within the kernel hacking section can be enabled for once.
12:48 AM memfrob: RTAI will soon be supported on kernels 4.4.87 (latest) and 4.9.49 (latest)
12:49 AM memfrob: I'll be working on that next if anyone is interested.
01:28 AM KimK: memfrob: Excellent! I'd be interested in trying them when they're ready.
01:29 AM KimK: Rats, too slow.
01:46 AM CaptHindsight: KimK: I'll get you his git tree
01:47 AM CaptHindsight: KimK: you can always find him through me
07:31 AM memfrob: 3.10.107 (latest) and 3.16.47 (latest) with patches broken up and debugging options fixed: https://github.com/NTULINUX/RTAI/tree/master/base/arch/x86/patches
07:32 AM memfrob: I was initially chasing my tail with the 3.16.47 kernel patch, for some reason that kernel hates my R9 290X -- I can't get login via X with it, took me a few hours to realize that adding radeon.modeset=0 to my kernel params fixed it.
07:33 AM memfrob: I admit the debugging options, especially when it's loaded full of everything, it hurts real-time performance but that's because it's truly slowing down the kernel by that much with the constant internal checks.
07:35 AM memfrob: I haven't compile tested those in a 32-bit environment so if you get any errors, let me know KimK I'll be glad to fix them. If anything it'll be in either ia32entry.S or entry_32.S (assembly code is not my specialty)
07:41 AM memfrob: At least kernel debugging is no longer fatal, I've been cherry-picking commits from the IPIPE code for 4.4 and such and backporting stuff like a mad man.
11:14 AM memfrob: Just finished re-writing RTAI 5 as well, dropped IPIPE legacy support in a separate branch, needed to do so to surpass 4.1 kernel
11:16 AM memfrob: All the new calibration stuff / HAL and scheduler from RTAI 5 merged into my squeaky clean tree, still keeping the math fixes that jepler and I worked on, will push once tested.
11:17 AM memfrob: I still don't like the idea of having to compile newlib so rtai_math.ko is still built the old-fashioned way.
11:17 AM memfrob: 4.9 support will be a breeze now, break time!
11:45 AM jepler: if I get back to looking at RTAI kernels it'll be for uspace+rtai, in which we can finally get rid of kernel modules (and worrying about FP math in the kernel) for once and for awesome
11:46 AM jepler: (which is in master branch, just nobody is using it and it probably has bugs:-P)
02:15 PM dgarr: any objections to changing biquad.comp parameters to pins (master branch)?
02:15 PM dgarr: would make on-the-fly filter changes easier to implement
02:22 PM Tom_itx: as programmers i though you might get some humor from this: https://jroweboy.github.io/c/asm/2015/01/26/when-is-main-not-a-function.html
02:31 PM jepler: dgarr: does it work properly in the case?
02:32 PM jepler: hal/components/biquad.comp: In function ‘_’:
02:32 PM jepler: hal/components/biquad.comp:141:24: error: lvalue required as left operand of assignment
02:32 PM jepler: n0 = b0 / a0;
02:32 PM jepler: ^
02:32 PM jepler: for me it doesn't compile when I change the "param rw" to "pin in"
02:32 PM jepler: e.g.,
02:32 PM jepler: -param rw float n0 = 1.0 "non-delayed numerator coef";
02:32 PM jepler: +pin in float n0 = 1.0 "non-delayed numerator coef";
02:32 PM dgarr: i haven't modified it yet, i am asking if there are objections
02:33 PM jepler: no, I don't care
02:33 PM jepler: I mean, I don't object
02:36 PM dgarr: ok thanks -- i don't think there will be issues as any existing setp will work with both params or pins (and there are likely few users)
02:37 PM jepler: I admit I had to check just what biquad even was
02:46 PM memfrob: Hey so I got 4.1.43 working but the kernel is asking me which CPU I'll be using for real-time tasks, did LinuxCNC ever figure out _for sure_ which one to start the RT-thread on?
02:49 PM memfrob: https://cateee.net/lkddb/web-lkddb/RCU_NOCB_CPU.html
02:49 PM memfrob: If LinuxCNC only uses core 0 then you'd select CONFIG_RCU_NOCB_CPU_ZERO If I understand this right.
02:50 PM memfrob: https://cateee.net/lkddb/web-lkddb/RCU_NOCB_CPU_ALL.html and https://cateee.net/lkddb/web-lkddb/RCU_NOCB_CPU_ZERO.html
02:53 PM jepler: memfrob: The intent of the code in LinuxCNC today is to put the RT code on the last CPU
02:54 PM CaptHindsight: last = highest number
02:54 PM jepler: yes
02:54 PM jepler: /* on SMP machines, we want to put RT code on the last CPU */
02:54 PM jepler: n = NR_CPUS-1;
02:54 PM jepler: while ( ! cpu_online(n) ) {
02:54 PM jepler: n--;
02:54 PM jepler: }
02:54 PM jepler: rtapi_data->rt_cpu = n;
02:55 PM memfrob: In that case, CONFIG_RCU_NOCB_CPU_NONE then append rcu_nocbs=3 (in my case, on a 4 core system) to the kernel command line
02:55 PM jepler: in the kernel space rtai we use this code to decide what CPU number to use
02:56 PM memfrob: I forget, has there / is there a way to test to see which core the RT thread itself is running on?
02:56 PM CaptHindsight: will only be ZERO on a single core cpu
02:56 PM jepler: in user space (for uspace+rtai as well as uspace+preemptrt) we have a more complicated method involving sched_setaffinity, but the intent is still to determine the highest numbered CPU and bind to it
02:56 PM memfrob: top/htop shows "latency-test" but I don't think "linuxcnc" "axis" or "latency-test" is the actual RT thread itself
02:56 PM jepler: I think that for RTAI, information about the CPU mask has historically been in some file in /proc, but I don't know the details offhand and I don't have an RTAI system handy to check.
02:57 PM memfrob: I know where the CPU mask info is, is that where I need to look?
02:58 PM jepler: in linuxcnc with kernel space RTAI, the threads are created from kernel space and I don't think they have a UNIX PID associated with them or show in (h)top
02:58 PM jepler: so .. yes ?
02:59 PM memfrob: Also, for some reason, I can't specify NO_HZ_FULL with IPIPE enabled, I'm going to try editing that in Kconfig and see what happens.. https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
02:59 PM dgarr: jepler: re biquad.comp: the d1,d2,n0,n1,n2 will remain params -- i doubt if they are ever used (because f0,Q are the common method to specify); s1,s2 will be output pins for test only (one would never set them as they are internal state)
03:00 PM memfrob: I'll play around with the callback and /proc and look for latency changes, thanks!
03:02 PM jepler: dgarr: makes more sense than changing them wholesale
03:02 PM jepler: dgarr: I assume you also noticed how d/n are only recomputed now when changing from disabled to enabled..?
03:02 PM jepler: or at least that is how I read it
03:06 PM dgarr: yes -- i have noticed -- it is a little inconvenient but avoids unexpected transient i suppose
03:22 PM memfrob: brb
10:04 PM Tom_itx is now known as Tom_L