Hey Alec,
Two things to report:
First, rtai_hal.ko was refusing to load because my system has 12 cores
but the package was built with CONFIG_RTAI_CPUS=8. The error message was
misleading ("Operation not permitted"), but dmesg showed "RTAI
CONFIGURED WITH LESS THAN NUM ONLINE CPUS". Fixed it by booting with
maxcpus=8.
After that, the RTAI testsuite works fine:
```
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| -655| -655| -81| 5586| 5586| 0
```
The problem is rtai_math.ko. It fails to load:
```
rtai_math: Unknown symbol __math_divzero (err -2)
rtai_math: Unknown symbol __log_data (err -2)
rtai_math: Unknown symbol fma (err -2)
```
I ran nm on it and those three symbols are listed as U (undefined).
They're internal musl helpers that get called by the higher-level math
functions (pow, log, etc.) but they weren't linked into the module. The
musl code itself is fine, the issue is just that these objects didn't
make it into rtai_math.ko during the build.
The RTAI testsuite doesn't load rtai_math.ko so it passes, but LinuxCNC
needs it for all its RT modules (motmod, tpmod). Without it nothing can run.
I can see from your screenshots that latency-histogram runs on your
system with HAL threads, so rtai_math.ko must load fine there. On my
Trixie install (GCC 14.2.0-19, same as the kernel headers) it doesn't.
What distro/version did you build the packages on? Maybe there's a
binutils or linker difference causing the symbols not to get pulled in.
Luca
On 4/1/26 1:13 PM, Alec Ari via Emc-developers wrote:
Yes, 5.4.280 works but parallel cards have not yet been tested with it. The
reason I went with musl is due to correctness and portability. Adding glibc to
kernel space is overkill and adds way too much. You actually need to strip out
a lot from the glibc library in order for it to work whereas musl is a lot more
modular.
Don't worry about the musl math library at all, that stuff is well tested and
true.
Two things... Make sure the RTAI testsuite works:
sudo /usr/realtime-5.4.280-rtai-amd64/testsuite/run
and `halrun -U` should unload the RTAI modules.
On Wednesday, April 1, 2026 at 12:03:12 AM CDT, Luca Toniolo<[email protected]>
wrote:
is the 5.4.280 supposed to work? I cannot fix the rtai_hal.ko not loading
Why are you not using Trixie glibc/libm? Was the package not for debian 13?
On April 1, 2026 12:54:03 PM GMT+08:00, Alec Ari via
Emc-developers<[email protected]> wrote:
Not very... Each major kernel release requires a lot of work. IPIPE is from Xenomai but slightly
modified for RTAI which is then called "hal-linux."AlecOn Tuesday, March 31, 2026 at
07:34:33 PM CDT, andy pugh<[email protected]> wrote: On Tue, 31 Mar 2026 at 22:39, Alec Ari
via Emc-developers<[email protected]> wrote:Sadly, IPIPE isn't patched that
far ahead. 5.4 or 4.19 are the only choices right now.Who does IPIPE? How non-portable is the patch
between kernels?
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
