Jetson nano install preempt RT successfull and build ethercat IGH module problem

After I installed preempt according to the above article, I could compile successfully and enter the system normally.
I run uname -a and see

Linux jetson 4.9.253-rt168-lb #1 SMP PREEMPT RT Fri Oct 28 15:51:26 CST 2022 aarch64 aarch64 aarch64 GNU/Linux

However, when I tested the delay, I felt that the RT was not functioning properly because the delay was relatively large.

Then I want to compile and install ethercat igh

I found that there are two directories under this,

/lib/modules/4.9.253-tegra/ /lib/modules/4.9.253-rt168-lb/

And when I ran sudo make modules_install, I found that the module file was placed in


instead of


So when I load the modules

modprobe ec_master

he reported an error

modprobe: FATAL: Module ec_master not found in directory /lib/modules/4.9.253-rt168-lb

So I copied the modules to


then run again

modprobe ec_master

The error is as follows

modprobe: ERROR: could not insert 'ec_master': Exec format error

./configure --with-linux-dir=/usr/src/linux-headers-4.9.253-tegra-ubuntu18.04_aarch64/kernel-4.9/ --with-module-dir=ethercat --enable-debug-if =no --disable-8139too --prefix=/opt/etherlab --enable-r8169=yes

1,Excuse me, after patching, do I need to manually open the preempt rt to enter the system?

2,I think my compiled module is put into the normal kernel module, not the RT kernel module,why?

3,Could it be that the source code under /usr/src has not been patched, so the compiled module cannot use the RT kernel?


I don’t know much about the preempt patch, but I can give some information to clarify.

A kernel has most of its functions built in. In many cases this can be built as a module, which is still part of the kernel, but can load and unload as it runs. When a module is loaded the specification of where to look for the module is built into the kernel itself. The output of “uname -r” is a prefix of the source code version, and a suffix of the CONFIG_LOCALVERSION at the time of compile. The search location becomes:
/lib/modules/$(uname -r)/kernel

If the kernel source is 4.9.253, and CONFIG_LOCALVERSION is set to “-tegra” at the time of build, then “uname -r” becomes “4.9.253-tegra”. Similarly, if the source code is 4.9.253, and “uname -r” results in “4.9.253-rt168-1b”, then it implies CONFIG_LOCALVERSION was set to “-rt168-1b” at the time of compile.

If a kernel has a certain configuration, then it is possible that a module is incompatible with that configuration since some features require others to work. Similarly, it is possible that one feature conflicts with another, and thus not all features can be present simultaneously. In order to add a new feature to an existing kernel one must start with a configuration and base kernel source code release which matches the original, followed by adding a new feature/symbol. An RT patched source is not a match with a non-RT source, and thus if you are to build a module, then that module must be built with the same starting patches and the same configuration. Failure to do so implies the module will have a conflict and fail to load.

exec format error would normally mean the kernel was built with the wrong architecture, e.g., for a desktop PC processor, but attempting to run on the wrong type of CPU (e.g., the arm64 processor of a Jetson does not match the processor of a desktop PC). However, there was a recent thread on the forum where it was found that this was a “bad error message” which could also occur if the starting configuration had a conflict as well. The fact that you have a “uname -r” suffix of “-rt168-1b”, and yet the source wanted to install with a suffix of “-tegra”, says that even if the source code is the same, then the configuration differed, and module load is likely to fail (at least module search would be to the wrong location).

The fact that you’ve built against the “-tegra” kernel source, and not the patched RT source, also says the module from one will fail when used with the other.

In order for this to work you’ll need both the “-rt168-1b” source code and the module compiled against the configuration which existed at the time of creating “4.9.253-rt168-1b” before you can add a new module. Modules in the old “/lib/modules/4.9.253-tegra/” cannot be used in the new kernel.

The configuration is probably different when bulding the RT sources, but I don’t know which config was used. Typically though, the running kernel will show its build configuration in “/proc/config.gz”. If you start with a copy of that, gunzip it to decompress, and rename it as “.config”, then this (plus setting CONFIG_LOCALVERSION to “-rt168-1b” in the RT source) will be a matching start config. The default config is from the “tegra_defconfig” target, but since you are using RT source, then likely that config is no longer valid.

I’ll also add that having RT source does not magically lower latency. You probably need to specify particular processes which should be scheduled for lower latency. If everything could be lower latency by this method, and no adjustment were needed to tune this, then everyone would use this source. You’d have to consult the documents on specifying scheduling classes (and in turn marking your process as that class).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.