R: Xenomai 3.1 application compatibility with newer kernels

Dear Jan,

thank you for your input. I've reverted to xenomai 3.1.7 and can confirm it works perfectly with kernel 5.4.299.
This solved our problem with the library, and we will stick with this solution until a newer version of the library will be available. 
Unfortunately it is closed source, so we can only push the supplier. 

It would be more informative to dig the issue with traces as you suggest, but I don't even know where to start...
Thank you again for the time and, most importantly, for the big work you (and the community) are doing around Xenomai project. 

Best regards

Davide Gandolfi
Laser Technology Development Engineer
ADIGE S.P.A.
A  via per Barco 11- 38056 Levico Terme (TN), Italy
T  +39 0461 729000 
F  +39 0461 701410
E  [email protected]
C  c.f. e reg. imp. 01429670225
C  cap. soc. 3.100.000,00 i.v.
W  Protected link to blmgroup.com
 
“Ai sensi del Reg. UE 2016/679 si rende noto che le informazioni contenute nell’email ed eventuali allegati hanno natura professionale, confidenziale e riservata e sono dirette a uno specifico destinatario. Nel caso abbiate ricevuto questa email per errore, vi preghiamo di darne immediata notifica al mittente e di eliminarla dal vostro computer. L’uso non autorizzato, la lettura, la stampa, la copia, l’inoltro, la diffusione delle informazioni stesse sono severamente vietati. Grazie per la collaborazione. 

Pursuant to Reg. UE 2016/679 we hereby inform you that the information contained in this email and in the attachments (if any) are of a professional nature, confidential and addressed only to the intended recipients. If you have received this email in error, please immediately notify the sender and delete it from your computer. It must not be read, copied, disclosed, printed, forwarded, relied upon or used by any person other than the intended recipient. Unauthorised use, disclosure or copying is strictly prohibited. Thank you in advance for your cooperation.”
-----Messaggio originale-----
Da: Jan Kiszka <[email protected]> 
Inviato: giovedì 5 marzo 2026 18:43
A: Lasertech Adige <[email protected]>; [email protected]
Oggetto: Re: Xenomai 3.1 application compatibility with newer kernels

On 05.03.26 18:33, davide gandolfi wrote:
> Dear community,
> 
> I have an application (a library) that is linked against Xenomai 3.1 (I bet using the Posix skin), and runs fine with kernel 4.19.114-cip24. In particular, it uses RtNet drivers.
> Now I need to update the hardware, and most solutions on the market have newer cpus not supported by that kernel. What are my best options?
> 
> On the ipipe-x86 repository, I see that kernel 5.4 is supported, but it is not clear to me if Xenomai 3.1 supports it.

We stopped testing against 5.4, but 3.1 used to support it.

> Moreover, 5.4 is still too old for Alder Lake or newer processors.
> Then, we have the dovetail repository, which is the most updated, but I think it does not fit with Xenomai 3.1, am I correct?

Correct, you need 3.2 at least for dovetail-based kernels.

> Lastly, I could update Xenomai to 3.3.x and use the latest dovetail kernel. This is what I did and the system works fine with basic tests (like "latency"), but works horribly with my old library.
> In particular, I have several spurious relaxes and mode switches on 
> the thread that, I guess, is responsible of calling the RtNet driver (not 100% sure on that because the library is closed source).

You can use system-level tracing (trace-cmd & Co.) to understand at least from the kernel perspective what is going on, e.g. which syscalls are issued or what other reasons there are for relaxes.

> 
> What are your thoughts? Is it expected that the API, in particular for RtNet, changed from Xenomai 3.1 to 3.3? Please note that I don't have any segmentation fault or crash, the application seems to work fine, just not "realtime". Shall I expect better compatibility if using Xenomai 3.2 or it is not worth trying?

I would not expect the issue in RTnet, specifically as that code barely changed in the past releases. But let's collect the real reasons first (see above) before speculating about them further.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center