Configuration for RTAI packages

[ShabbyX]

Following the discussion on #16, we'd like to figure out what particular configuration you use for RTAI in your application, so we can include it during the configuration of the Debian, Red Hat, etc packages.

Please reply with a comment indicating what configuration you change from the default and what value you set it to.

There is no need to include all the default configuration. If you don't remember what is the default, it's ok to also include configuration that is important to you (Just avoid copy pasting your configuration).

[ShabbyX]

For myself:

• In Base system ---> Supported services, enable Semaphores and Shared memory (probably this is default, though).
• In Base system ---> Scheduling options, set Number of registrable RTAI objects to a high value. I often use 4096.
• In Base system ---> Other features, disable Real-time malloc support (rtai_malloc failed creating more than 60 kernel threads with my tests).
• In Base system ---> Scheduling options, enable Display RTAI task execution time (in my own fork of RTAI on github, there is a function that returns the precise execution time of the task, so this option is not necessarily just for displaying execution time anymore).
• In Add-ons, enable Real-Time Driver Model over RTAI.

[Lukas0907]

Hi,

I use Linux 3.10.40 with all Debian patches available for that kernel version (http://snapshot.debian.org) and latest RTAI patch from magma for 3.10 in conjunction with RTAI 4.0 and patches to enable support for 3.10 on top of RTAI 4.0. For that purpose I've updated the original RTAI Debian package which is stuck at 3.8.

Kernel wise I use the default Debian configuration for 686-pae and based on that disable the following three configuration entries:

## Disable CPU frequency scaling which can lead to stalls on CPUs/tasks
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_CPU_FREQ is not set

I try to maintain my patches and the kernel as close as possible to the way Debian does it. That way I'm able to build new minor kernel versions within a few minutes work (compilation takes a bit longer, of course) and have all my modifications revisioned.

Regards,

Lukas

[zultron]

Also handy would be a reasonable set of args for ./configure.

[ShabbyX]

@Lukas0907 , while this information is valuable, the issue is about RTAI's configuration, rather than the kernel's.

[zultron]

Hi @Lukas0907,

Here's the kernel .config snippet that gets overlaid onto a vanilla config in the RTAI kernel packaging. Looks like those ones you mentioned are already covered. There's also a handful of other configs that came from the Xenomai .config snippet, which I hope are applicable to all ipipe-based RT kernels.

https://github.com/zultron/kernel-rt-deb/blob/3.8.13/config/featureset-rtai.x86/config

[zultron]

And here are the options to ./configure in the RTAI package. The first is how RTAI is configured during the kernel package build (RTAI kmodules are built inside the kernel package). The second is how the RTAI run-time is configured (librtai, etc.).

This split-personality config is inherited from the upstream Debian packaging. I'm guessing the runtime args to ./configure contain --enable-comedi-lxrt --enable-comedi-lock while the kernel build args don't is because those are strictly user-land features that don't need to be built for kmodules.

https://github.com/zultron/rtai-deb/blob/master/rules#L151-L158 https://github.com/zultron/rtai-deb/blob/master/rules#L211-L216

[ShabbyX]

The ./configure options seem reasonable. The kernel configuration is gold. We've been dying to have a recent set of to-does and not-to-does!

[zultron]

Thanks, @ShabbyX. I have some nearly completely untested Debian packages online that passed basic tests on amd64 (single CPU; rumors say multi-CPU will require isolcpus module args?). I've invited a couple of others for initial testing.

If you'd like to try, configure the 3rd-party Apt repo as described here.

Install one of these x86 'flavour' package sets:

linux-image-3.8-1-rtai.x86-686-pae
linux-headers-3.8-1-rtai.x86-686-pae

linux-image-3.8-1-rtai.x86-amd64
linux-headers-3.8-1-rtai.x86-amd64

Plus 'flavour'-independent packages:

librtai1
librtai-dev
linux-headers-3.8-1-common-rtai.x86 

Addressing the problem in #16, rtai-config -l should discover the linux-headers-3.8-1-rtai.x86-<flavour> package headers, along with any other headers known by other rtai-config* executables in $PATH. Select one with rtai-config -v <kver>, where <kver> is one of the output of the -l switch, and append the usual rtai-config arguments. (No -v <kver> will select the running kernel by default, but print ugly warnings about it.)

No expectations at all for you to test these, but if you do, I fully expect you to report back with results. ;)

[ShabbyX]

I'm away this weekend, but I'll try to give them a try next week. I'd surely let you know!

About multi-core CPUs, I doubt isolcpus would be necessary. The reason to isolate CPUs is to make sure Linux never runs on the same CPUs as real-time tasks (I don't know, maybe so it wouldn't dirty its cache, or could it make the CPU fail for some reason?). Anyway, RTAI should work fine on multi-CPUs. If it doesn't, it should be fixed!

[ShabbyX]

@zultron, is the configuration given to ./configure the only configuration you use and the rest is the default? Or do you do make menuconfig or equivalent after? If not, then I'll try to look for options to give to ./configure to at least cover the other configuration I mentioned above. For example a higher number of possible objects.

[zultron]

That's a piece the Debian maintainers have taken care of. Looks like they use base/arch/x86/defconfig:

https://github.com/zultron/rtai-deb/blob/master/rules#L348-L349 https://github.com/zultron/rtai-deb/blob/master/rules#L147-L149

If you want to change the defaults, I suggest dropping a patch into the RTAI packaging, or else getting the upstream maintainers to change the defconfig file. ;)

[ShabbyX]

@zultron upstream is an unmoving stone! I'll update the defconfig in ShabbyX/RTAI, thanks.

[ShabbyX]

@zultron the defconfig files for both x86 and x86_64 are now updated (I updated the configuration for x86, but copied to both, so they are identical. I assume that should be fine)