Fix priority check for LXRT

[hdiethelm]

Based on this comment #3878 (comment), I track down the issue and fixed it.

It was introduced here:
233f381

git tag --contains 233f381
v2.10.0-pre0
v2.9.0
v2.9.0-pre1
v2.9.1
v2.9.2
v2.9.3
v2.9.4
v2.9.5
v2.9.6
v2.9.7
v2.9.8

That's why 2.9.0-pre0 in the picture was probably still working, however, I dont't have such an old VM to test this theory.

The issue is this check:

linuxcnc/src/rtapi/uspace_rtapi_app.cc

Line 900 in 233f381

if ((prio > rtapi_prio_highest()) || (prio < rtapi_prio_lowest()))

It fails when the lowest prio is bigger than the highest:
#define RT_SCHED_HIGHEST_PRIORITY 0
#define RT_SCHED_LOWEST_PRIORITY 0x3fffFfff
The above commit introduced a fix returning the correct prio for LXRT and broke the check with that.

Tested with:
POSIX non-realtime
POSIX realtime
XENOMAI (posix-skin) realtime
LXRT realtime

Just tell me if branch 2.9 is wrong for this fix and I will rebase to master.

[andypugh]

I tried to build this PR with:

./configure --with-realtime=uspace --enable-build-documentation=none

On the 5.4.279-rtai kernel with Debian Trixie

I get the following error, any thoughts:

Linking rtapi_app
Compiling rtapi/uspace_rtai.cc
In file included from rtapi/uspace_rtai.cc:10:
/usr/include/x86_64-linux-gnu/sys/io.h:38:12: error: declaration of ‘int iopl(int) noexcept’ has a different exception specifier
   38 | extern int iopl (int __level) __THROW;
      |            ^~~~
In file included from /usr/include/rtai/rtai_lxrt.h:524,
                 from rtapi/uspace_rtai.cc:6:
/usr/include/rtai/asm/rtai_lxrt.h:170:38: note: from previous declaration ‘int iopl(int)’
  170 | #define rtai_iopl()  do { extern int iopl(int); iopl(3); } while (0)
      |                                      ^~~~
/usr/include/rtai/rtai_lxrt.h:607:9: note: in expansion of macro ‘rtai_iopl’
  607 |         rtai_iopl();
      |         ^~~~~~~~~
make: *** [Makefile:287: objects/rtapi/uspace_rtai.o] Error 1
make: Leaving directory '/home/andypugh/linuxcnc-dev/src'

I suspect that this is a consequence of the long and complex history of this particular VM.

[hdiethelm]

I should probably also create an issue for https://github.com/NTULINUX/RTAI
I think this is in a package from there. rtai-modules-5.4.279: /usr/include/rtai/asm-x86/rtai_lxrt.h

This change will fix it:

--- rtai_lxrt.h.orig	2026-03-23 21:21:53.462988753 +0100
+++ /usr/include/rtai/asm-x86/rtai_lxrt.h	2026-03-23 21:22:24.946592950 +0100
@@ -167,7 +167,7 @@
         return ret;
 }
 
-#define rtai_iopl()  do { extern int iopl(int); iopl(3); } while (0)
+#define rtai_iopl()  do { extern int iopl(int) __THROW; iopl(3); } while (0)
 
 #endif /* __KERNEL__ */

I mentioned it already here but there are many things going on: #3873 (comment)

I think you will have the same issue on master and 2.9.