From Xenomai

On an embedded platform, configuring the Linux kernel is usually easy: the Linux kernel has a defconfig file, you just start from this defconfig, add Xenomai options, tweak a few bits here and there, and you are done.

Configuring x86 kernels is a bit different, there are no defconfig files for all standard PC models around, and the only kernel configuration file you may want to start from is your distribution's configuration file. Unfortunately, the typical one-fits-it-all configuration shipped with any desktop/server distribution is always conflicting with real-time requirements these days.

So here are a few guidelines in order to configure a kernel for Xenomai.

Processor type

Choose the exact processor your PC is using, do not choose something like "generic i586", as, in that case, Xenomai would not use the x86 time stamp counter, which helps reducing the overhead. If, for any reason, you have to use Xenomai on a PC without a TSC, please keep CONFIG_INPUT_PCSPKR disabled.

Power management

Do not disable power management globally, the only configuration options which should be disabled in this area are:

• CONFIG_APM
• CONFIG_ACPI_PROCESSOR

for reasons mentioned here:

http://www.xenomai.org/index.php/FAQs#Tips_and_tricks_setting_up_your_x86_kernel

In particular, keeping the ACPI enabled bears no risks of high latencies, whereas disabling it may prevent your system from booting correctly.

USB

In the same vein, do not disable USB, enable support for your USB host controller(s), as the host controller code, when starting, disables support for "legacy USB emulation", which is a source of high latencies.

CPU Frequency scaling

Disable CONFIG_CPU_FREQ, this option creates issues with Xenomai timing code, as well as unpredictable run-time for your tasks, and possibly high latencies when changing frequency.

Timing should be correct with recent processors having the "constant_tsc" flag, advertised in /proc/cpuinfo, but the uncertainty on the run-time of real-time tasks remains. Also keep in mind that in that case, the "ondemand" governor will not be able to take into account of the run-time of real-time tasks running in primary mode, to switch to high frequency in case of power request.

Message Signaled Interrupts (MSI and MSI-X)

The option CONFIG_PCI_MSI should be turned off. For more details, see the thread at: https://mail.gna.org/public/adeos-main/2008-08/threads.html

Booting with or without an initramfs?

By default, distributions kernels boot using an initramfs. This means that the kernel needs no particular built-in support, anything can be built as a module. These modules are loaded in a first boot stage, from the initramfs, then the final root filesystem may be mounted and the kernel boot may continue normally.

So, if you start from a distribution kernel, you will have to generate an initramfs containing the modules supporting the basic hardware needed to mount root filesystem. Eache distribution provides its way to generate an initramfs for a new kernel.

If, on the other hand, you want to boot without an initramfs, you will have to build inside the kernel, and not as a module, all the components necessary for mounting your root filesystem. This means: the disk controller support, the support for SCSI disks if this controller is an SCSI controller or is supported by a new style ATA controller, the support for IDE disks if this controller is supported by an old-style Parallel ATA controller, the support for your NIC if booting through network, and the support for the filesystem used by your root filesystem (e.g. EXT3, NFS, etc...).

There is one thing for sure, however: you can not boot a kernel where everything is built as a module, without an initramfs.

In case of high latencies

The most common reason for high latencies on x86 are SMIs.

There is an "SMI workaround" option available in the Xenomai section of the Linux kernel configuration menu, in order to forbid such SMIs. If this option is enabled, and do not see any Xenomai message about SMIs in the kernel logs, it means that your chipset is not supported. If it is an Intel chipset, you should try and add the PCI IDs (obtained with lspci -nn) of the LPC component of the chipset to the PCI IDs table in ksrc/arch/x86/smi.c. Please report your results to Xenomai-help mailing list, so that we may add the necessary bits to handle your chipset to the Xenomai core if applicable.

In case you decide to try and enable the "SMI workaround", please read the Troubleshooting guide.

Other sources of high latencies are documented in this guide.

Internet archives

There should not be more options to tweak than the one mentioned on this page.

If you find some mails in our archives saying "please disable option X or Y", please do not conclude that you should disable these options. Such answers are usually attempts to find what is wrong in a user setup.

If you find some other options mentioned on some other web sites talking about Xenomai, they possibly mis-interpreted such posts from our mail archives. Please make sure to ask on the Xenomai-help mailing list for confirmation.

Does Xenomai work?

When booting a correctly configured kernel, you should see the messages ressembling these in the kernel logs:

I-pipe: Domain Xenomai registered.
Xenomai: hal/x86_64 started.
Xenomai: real-time nucleus v2.5-devel (Flying In A Blue Dream) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.

If you do not see these messages (in particular, if the messages indicate that Xenomai initialization failed, or you do not see any message about Xenomai at all), then something went wrong, and you should refer to the TROUBLESHOOTING guide, and if that fails post to the Xenomai-help mailing list.