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).