FAQs

From Xenomai

Jump to: navigation, search

[edit] General

  • What is the current status of the different ported arch's?
    • x86: from i386 to latest Pentiums and AMD's, UP and SMP
    • x86_64
    • PowercPC (2.6.19-ppc, 2.6.20-powerpc):
      • Freescale family: PowerQUICC I, PowerQUICC II, PowerQUICC III, ..
      • AMCC family: 405, 440, ..
    • PowercPC 64 (2.6.22-powerpc)
      • PA6T
    • IA64
    • ARM cores:
      • Integrator/CP ARM 1136
      • PXA
      • SA1100-based
      • Freescale iMX21/csb535fs
      • Atmel at91rm9200 (tested on CSB637)
      • Samsung S3C24xx
      • Intel ixp4xx
      • Atmel at91sam926x
      • Motorola i.MX family
    • Analog Devices Blackfin BF533, BF537 and BF561
    • MIPS: not distributed yet
    • SH-4 (SH7750R)/SH-3: not distributed yet

This list may not be accurate. Please update depending on developement of ADEOS/I-Pipe patch and Xenomai project. If unsure, ask on the mailing-list.

  • Is ARM board X supported by Xenomai ?

There is no ARM board specific code in Xenomai, the only ARM board specific code is in the ARM I-pipe patch. You will find the list of the boards which the ARM I-pipe patch supports in the file ksrc/arch/arm/patches/README of Xenomai source distribution.

If your board is not supported, check the following HOWTO to see what work is needed to port the I-pipe patch to a new board. For more details, please do not hesitate to ask questions on Xenomai mailing lists.

Here is a page on porting from RTOS. If your favorite skin is not in the list, please ask on the mailing list.

  • What are the differences between Xenomai and RTAI?

There is actually a long list of differences, though both projects share a few ideas and support the RTDM layer. The major differences derive from the goals the projects aim for, and from their respective implementation. While RTAI is focused on lowest technically feasible latencies, Xenomai also considers clean extensibility (RTOS skins), portability, and maintainability as very important goals. Xenomai's path towards PREEMPT_RT support is another major difference compared to RTAI's objectives.

One Xenomai developer once expressed his point of view on this comparison in the following posting: Xenomai vs. RTAI.

[edit] Installation and Setup

  • What are recommended kernel settings?
    • CONFIG_XENO_HW_SMI_WORKAROUND: Tries to disable System Management Interrupts on Intel chipsets. These interrupts run at higher priority than Xenomai core code or even the I-pipe layer. So they can cause high latencies to the real-time jobs (up to miliseconds).
      ATTENTION: On some systems, SMI may be involved in thermal throttling of the CPU. Thus, switching it off can cause hardware damage in overheat scenarios.
    • Optimised CPU and platform settings: By tuning your kernel settings close to the real hardware, you can avoid unneeded overhead (e.g. CONFIG_SMP on non-SMP systems) or suboptimal code generation (e.g. CONFIG_M586 enables TSC emulation even if the CPU provides this feature).
  • Which kernel settings should be avoided?
    Note that Xenomai will warn you about known invalid combinations during kernel configuration.
    • CONFIG_CPU_FREQ: This allows the CPU frequency to be modulated with workload, but many CPUs change the TSC counting frequency also, which makes it useless for accurate timing when the CPU clock can change. Also some CPUs can take several milliseconds to ramp up to full speed.
    • CONFIG_APM: The APM model assigns power management control to the BIOS, and BIOS code is never written with RT-latency in mind. If configured, APM routines are invoked with SMI priority, which breaks the rule that adeos-ipipe must be in charge of such things. CONFIG_XENO_HW_SMI_WORKAROUND_* doesn't help here.
    • CONFIG_ACPI_PROCESSOR: For systems with ACPI support in the BIOS, this ACPI sub-option installs an 'idle' handler that uses ACPI C2 and C3 processor states to save power. The CPU must 'warm-up' from these sleep states, increasing latency in ways dependent upon both the BIOS's ACPI tables and code. You may be able to suppress the sleeping with 'idle=poll' boot-arg, test to find out. With recents versions of Linux (probably starting around Linux 2.6.21), the acpi processor module disables the local APIC when loaded. This will cause Xenomai timer initialization to fail. This makes a second reason for disabling this option.
    • CONFIG_INPUT_PCSPKR (only if i386 && kernel 2.6 && no TSC available): Collides with Xenomai's TSC emulation on oldish x86 systems.
  • What can I do if Xenomai and Linux devices share the same IRQ?
    IRQ sharing between RT (Xenomai) and non-RT (Linux) domains is fragile, can easily destroy determinism on the RT side, and should therefore be avoided whenever possible. Sharing IRQs between RT devices is not problematic, but still comes with additional overhead compared to dedicated IRQ lines. The following approaches exist to untangle devices IRQ-wise:
    • If at least one of the devices is a PCI card, try to flip its position on the motherboard.
    • PC104+ cards sometimes have jumpers (yeah, they still exist) to change the IRQ line. Otherwise, their ordering in the PC104 stack also influences the IRQ line
    • Some (but not many) PC and notebook BIOSes allow to change the IRQ assignment.
    • Disable the conflicting Linux device (e.g. in the BIOS) or simply don't load its driver.
    • Disable some other on-board device that is unneeded. Sometimes this helps to persuade the system to avoid shared IRQs.
    • Ask you board vendor about possibilities to untangle IRQ lines -- or beat some engineer from your hardware design team if it is a homegrown problem.

[edit] Usage

  • How can Xenomai realtime tasks communicate with normal Linux tasks?

(overview / caveats / examples)

Inter Process Communication (IPC) between Xenomai task and Linux process

  • Skin usage

Can I use different skins simultaneously?

  • Which general Linux API functions are safe to call without switching from primary to secondary domain?

tbd.

  • Which debugging facilities are built-in into Xenomai and how should they be used?

( + Best practices in debugging realtime threads) tbd.

  • How can GDB be used?

tbd.

  • What do the entries of the /proc/xenomai directory mean ?

/proc/xenomai/sched

  • Which thread holds a Mutex?

I see a deadlock occur every now and then in my application. Is there a way to tell which thread is actually holding a lock from a normal userspace app? rt_mutex_inquire() only tells me that it is locked, but not who is holding it. 

/proc/xenomai/registry/native/mutexes/...
  • What may cause a freeze or machine lockup?
    • Stack space overflow issue now biting some real-time kernel thread?
    • Spurious delay/timeout values computed by the application (specifically: too short), as a side-effect of the timebase introduction?
    • A case of freeze is a system call called in a loop which fails without its return value being checked.
    • Software memory corruption (eg. dangling pointers)
    • Hardware memory corruption (eg. faulty RAM)
    • Termal watchdog kicking in

Since the nucleus watchdog does not trigger, you may want to try disabling X86_UP_IOAPIC while keeping X86_UP_APIC, and arm the kernel NMI watchdog on the LAPIC (nmi_watchdog=2). You may be lucky and have a backtrace after the freeze. Maybe enabling all the nucleus debug options would catch something too.


tbc.

Personal tools