Module: xenomai-3
Branch: next
Commit: 9633e2ddda4255a0b6a9008ae45faaac034e660e
URL:    
http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=9633e2ddda4255a0b6a9008ae45faaac034e660e

Author: Philippe Gerum <r...@xenomai.org>
Date:   Sun Sep 28 21:18:28 2014 +0200

doc/asciidoc: remove left over

---

 doc/asciidoc/TROUBLESHOOTING.adoc |  650 -------------------------------------
 1 file changed, 650 deletions(-)

diff --git a/doc/asciidoc/TROUBLESHOOTING.adoc 
b/doc/asciidoc/TROUBLESHOOTING.adoc
deleted file mode 100644
index 9938da8..0000000
--- a/doc/asciidoc/TROUBLESHOOTING.adoc
+++ /dev/null
@@ -1,650 +0,0 @@
-Troubleshooting guide for Xenomai 3.x
-=====================================
-
-This file is a troubleshooting guide about various known issues
-regarding Xenomai 3.x.
-
-[[kconf]]
-Kernel configuration
---------------------
-
-When configuring the Linux kernel, some options should be avoided.
-
-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_CPU_IDLE:: Allows the CPU to enter deep sleep states,
-increasing the time it takes to get out of these sleep states, hence
-the latency of an idle system. Also, on some CPU, entering these deep
-sleep states causes the timers used by Xenomai to stop functioning.
-
-CONFIG_KGDB:: This option can not be enabled with current versions of
-the I-pipe patch.
-
-For x86 specific options see also
-http://www.xenomai.org/index.php/Configuring_x86_kernels[this page].
-
-
-[[kerror]]
-Xenomai or I-pipe error in the kernel log
------------------------------------------
-
-If the Xenomai and I-pipe messages do not appear in the kernel
-log as:
-
-------------------------------------------------------------------------------
-I-pipe: head domain Xenomai registered.
-Xenomai: hal/<arch> started.
-Xenomai: scheduling class idle registered.
-Xenomai: scheduling class rt registered.
-Xenomai: real-time nucleus v2.6.1 (Light Years Away) loaded.
-Xenomai: debug mode enabled.
-Xenomai: starting native API services.
-Xenomai: starting POSIX services.
-Xenomai: starting RTDM services.
-------------------------------------------------------------------------------
-
-Where <arch> is the architecture you use, check the following
-sections, they describe the usual error messages you may encounter.
-
-
-The kernel stops after "Uncompressing Linux... done, booting the kernel."
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This means that the kernel crashes before the console is enabled. You
-should enable the +CONFIG_EARLY_PRINTK+ option. For some architectures
-(blackfin, x86, arm), enabling this option also requires passing the
-+earlyprintk+ parameter on the kernel command line. See
-'Documentation/kernel-parameters.txt' for possible values.
-
-For the ARM architecture, you have to enable +CONFIG_DEBUG_KERNEL+ and
-+CONFIG_DEBUG_LL+ in order to be able to enable +CONFIG_EARLY_PRINTK+.
-
-
-The kernel stops with an OOPS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Please make sure that you have followed the <<kconf,"Kernel
-configuration">> section. Then, try capturing the oops text (using a
-serial console or netconsole) post the oops to the
-mailto:xeno...@xenomai.org[xenomai mailing list], with the kernel
-configuration you used to compile the failing kernel.
-
-
-The kernel boots but does not print any message
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Your distribution may be configured to pass the +quiet+ option on the
-kernel command line. In this case, the kernel does not print all the
-log messages, however, they are still available using the +dmesg+
-command.
-
-
-I-pipe: could not find timer for cpu #x
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See <<ENODEV, code -19>>.
-
-
-Xenomai: Local APIC absent or disabled!
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See <<ENODEV, code -19>>.
-
-[[SMI]]
-Xenomai: SMI-enabled chipset found, but SMI workaround disabled
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First you should run the latency test under some load and see if
-you experience any pathological latency ("pathological" meaning more
-than, say, 100 micro-seconds). If you do not observe any such latency,
-then this warning is harmless, and if you find it annoying, you may
-disable "SMI detection" in Xenomai's configuration menu. You can skip
-the rest of this section.
-
-If you observe any high latency then you have a problem with SMI, and
-this warning was intended for you. But the Xenomai configuration menu
-allow you to enable two workarounds which may help you. These
-workarounds may be found in the Machine/SMI workaround sub-menu of
-Xenomai configuration menu.
-
-The first workaround which you should try is to disable all SMI
-sources. In order to do this, in the Xenomai configuration menu, select
-the options "Enable SMI workaround" and "Globally disable SMI". This
-option is the safest workaround, because when enabled, no SMI can
-interfere with hardware interrupt management behind your back and
-cause high latencies.  Once this workaround enabled, you should run
-the latency test again, verify that your high latency disappeared but
-most importantly, verify that every peripheral you intend to use with
-Xenomai is working properly. If everything is working properly, then you
-are done with SMI.
-
-If some peripheral is not working properly, then it probably needs
-SMI, in which case you can not simply disable SMI globally, you will
-need to disable all SMI sources on your system except the SMI needed
-by your peripheral. This is a much less safe choice, since Xenomai has
-to know all SMI sources to disable them, one by one. In order to
-choose this second workaround, unselect the option "Globally disable
-SMI", and select the option corresponding to your peripheral. For
-example, if you need legacy USB emulation to get your USB mouse
-working, select the option "Enable legacy USB emulation". You should
-then run the latency test again and verify that you do not observe any
-high latency and that all your peripherals are functioning
-correctly. If you can not find your peripheral in the list proposed in
-the Xenomai configuration menu, drop a mail to the
-mailto:xeno...@xenomai.org[Xenomai mailing list], we will try and
-possibly add the proper option if needed. If when running the latency
-test again, your peripheral is working properly and you still observe
-high latencies, then you are out of luck, the peripheral you want is
-likely to be the cause of such latencies.
-
-IMPORTANT: On some systems, SMI may be involved in thermal throttling
-of the CPU. Thus, switching it off *can cause hardware damage* in
-overheat situations. Do not disable SMIs if you are in this case.
-
-
-[[ENODEV]]
-Xenomai: system init failed, code -19
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The most probable reason is that Xenomai could not find a timer.
-
-Check that you have not enabled one of the options in the
-<<kconf,"Kernel configuration">> section.
-
-On x86
-^^^^^^
-
-You will most likely also see the following message:
-
---------------------------------------------------
-Xenomai: Local APIC absent or disabled!
-Disable APIC support or pass "lapic" as bootparam.
---------------------------------------------------
-
-Xenomai sends this message if the kernel configuration Xenomai was
-compiled against enables the local APIC support
-(+CONFIG_X86_LOCAL_APIC+), but the processor status gathered at boot
-time by the kernel says that no local APIC support is available.
-There are two options for fixing this issue:
-
-* either your CPU really has _no_ local APIC hw, then you need to
-rebuild a kernel with LAPIC support disabled, before rebuilding
-Xenomai against the latter;
-
-* or it does have a local APIC but the kernel boot parameters did not
-specify to activate it using the "lapic" option. The latter is
-required since 2.6.9-rc4 for boxen which APIC hardware is disabled by
-default by the BIOS. You may want to look at the file
-'Documentation/kernel-parameters.txt' from the Linux source tree, for
-more information about this parameter.
-
-
-On other supported platforms
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-As on x86, on other platforms where Xenomai shares the timer with
-Linux, the timer is only used if it was not shut down by Linux. So you
-should check the log for messages about disabled timers. You can also
-check '/proc/timer_list' to see which timers are enabled. For
-instance, Xenomai on SMP systems requires per-cpu local timers, so the
-local timers should be enabled. In case of doubt, post a message to
-mailto:xeno...@xenomai.org[the xenomai mailing list], sending:
-
-* your kernel configuration
-* the contents of '/proc/timer_list' run on the exact kernel which has the 
issue
-* the complete kernel boot log.
-
-
-On a new I-pipe port
-^^^^^^^^^^^^^^^^^^^^
-
-You will most likely also see the following message:
-
---------------------------------------------------
-I-pipe: could not find timer for cpu #x
---------------------------------------------------
-
-Starting with the I-pipe patch for Linux 3.2, the timers provided by
-the I-pipe patch to Xenomai are registered at run-time. So, you may
-lack a +struct ipipe_timer+ definition, and its registration with
-+ipipe_timer_register()+ or with the +ipipe_timer+ member of the
-+struct clock_event_device+ structure.
-
-For an example on the ARM platform see
-http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#The_general_case[this
-page].
-
-
-Xenomai: system init failed, code -22
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-On the ppc64 platform, check whether +CONFIG_PPC_64K_PAGES+ is defined
-in your kernel configuration. If so, then you likely need to raise all
-Xenomai parameters defining the size of internal heaps, such as
-+CONFIG_XENO_OPT_SYS_HEAPSZ+, +CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ+ and
-+CONFIG_XENO_OPT_SEM_HEAPSZ+, so that (size / 64k) > 2. The default
-values for these parameters are currently based on the assumption that
-PAGE_SIZE = 4k.
-
-
-[[latency]]
-Problems when running the latency test
---------------------------------------
-
-The first test to run to see if Xenomai is running correctly on your
-platform is the latency test. The following sections describe the
-usual reasons for this test not to run correctly.
-
-
-Xenomai: --enable-x86-sep needs NPTL and Linux 2.6.x or higher
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-On the x86 architecture, the configure script option
-+--enable-x86-sep+ allows Xenomai to use the SYSENTER/SYSEXIT
-mechanism for issuing system calls.
-
-However, this mechanism requires support from the libc. Currently, we
-know the glibc with NPTL has this support, other libraries will cause
-Xenomai applications to fail with this error message.
-
-
-latency: failed to open benchmark device
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You have launched +latency -t 1+ or +latency -t 2+ which both require
-the kernel to have been configured with the
-+CONFIG_XENO_DRIVERS_TIMERBENCH+ option.
-
-Hardware tsc is not a fast wrapping one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See the <<arm-tsc, "ARM tsc emulation issues">> section.
-
-
-Xenomai: incompatible ABI revision level
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Each Xenomai branch (2.1, 2.2, 2.3, 2.4, 2.5, 2.6,...) defines a
-kernel/user ABI, so that it is possible to mix kernels and user-space
-supports of different versions in the same branch. So, for instance,
-after having build a system with a kernel and user-space support using
-Xenomai 2.6.0, it is possible to update the user-space support to
-Xenomai 2.6.1 without changing the kernel.
-
-However, it is not possible to mix kernel and user-space supports of
-different branches.
-
-A common reason for this error is when you run a kernel compiled with
-Xenomai 2.6.1 support on a system where you have a user-space
-installed by your Debian based Linux distribution (notably Ubuntu)
-from the 2.5 branch, this can not work, the two branches use different
-ABIs. See link:README.INSTALL.html[README.INSTALL] for details on how
-to compile a user-space support, or to build a new +xenomai-runtime+
-Debian package.
-
-If you compiled and installed the correct Xenomai user-space support,
-there are probably files on your system remaining from a previous
-installation.
-
-
-Xenomai: incompatible feature set
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Since kernel-space support and user-space support are compiled
-separately, each Xenomai application checks, at startup, whether the
-kernel and user-space supports have been configured with compatible
-options. If you see this message, it means they have not. See
-link:README.INSTALL.html#_feature_conflict_resolution[README.INSTALL]
-for further details. The following sections detail the most frequent
-reasons for this message.
-
-
-missing="kuser_tsc"
-^^^^^^^^^^^^^^^^^^^
-
-See the <<arm-tsc, "ARM tsc emulation issues">> section.
-
-
-missing="sep"
-^^^^^^^^^^^^^
-
-On the x86 architecture, the configure script option
-+--enable-x86-sep+ allows Xenomai to use the SYSENTER/SYSEXIT
-mechanism for issuing system calls.
-
-However, this mechanism requires a recent kernel (2.6 or higher).
-
-
-missing="smp/nosmp"
-^^^^^^^^^^^^^^^^^^^
-
-For kernel-space and user-space supports to be compatible, both should
-be compiled with the same setting for SMP.
-
-SMP support in kernel-space is enabled with the +CONFIG_SMP+ option.
-
-SMP support in user-space is enabled by passing +--enable-smp+ to the
-configure script, and disabled by passing +--disable-smp+ (SMP is
-enabled by default on some platforms).
-
-
-missing="tsc"
-^^^^^^^^^^^^^
-
-This error is specific to the x86 architecture. You enabled tsc in
-user-space by passing the +--enable-x86-tsc+ option, but you selected
-a processor when configuring the kernel which has no tsc.
-
-So, if your processor has a tsc (all Intel processors starting with
-some Pentium and Pentium Pro have a tsc), you probably mis-configured
-your kernel and should select the exact processor you are using in the
-kernel configuration and recompile it.
-
-If your processor does not have a tsc, you should not pass the
-+--enable-x86-tsc+ option to the configure script.
-
-
-Xenomai: kernel/user tsc emulation mismatch
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See the <<arm-tsc, "ARM tsc emulation issues">> section.
-
-
-Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Possible reasons for this error are:
-
-* you booted a kernel without Xenomai or I-pipe support, a kernel with
-I-pipe and Xenomai support should have a '/proc/ipipe/version' and
-'/proc/xenomai/version' files;
-
-* the kernel you booted does not have the +CONFIG_XENO_SKIN_NATIVE+ and
-+CONFIG_XENO_OPT_PERVASIVE+ options enabled;
-
-* Xenomai failed to start, check the <<kerror,"Xenomai or I-pipe error
-in the kernel log">> section;
-
-* you are trying to run Xenomai user-space support compiled for x86_32
-on an x86_64 kernel.
-
-
-latency: not found
-~~~~~~~~~~~~~~~~~~
-
-On the ARM platform this message happens when there is a mismatch
-between kernel and user for the EABI setting: for instance you
-compiled the user-space support with a toolchain generating OABI code,
-and are trying to run the result on a kernel with +CONFIG_AEABI+ but
-without +CONFIG_OABI_COMPAT+. Or vice versa, when running user-space
-compiled with an EABI toolchain on a kernel without +CONFIG_AEABI+.
-
-
-Xenomai: Your board/configuration does not allow tsc emulation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See the <<arm-tsc, "ARM tsc emulation issues">> section.
-
-
-the latency test hangs
-~~~~~~~~~~~~~~~~~~~~~~
-
-The most common reason for this issues is a too short period passed
-with the +-p+ option, try increasing the period.
-
-
-the latency test shows high latencies
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The latency test runs, but you are seeing high latencies.
-
-* make sure that you carefully followed the <<kconf,"Kernel
-configuration" section>>.
-
-* make sure that you do not have an issue with SMIs, see the <<SMI,
-section about SMIs>>. Note that if you have an Intel chipset and you
-do not see the message:
-
--------------------------------------------------------------------------------
-Xenomai: SMI-enabled chipset found, but SMI workaround disabled
--------------------------------------------------------------------------------
-in the boot logs, it may mean that your chipset is not detected.
-
-* if you have some legacy USB switch at BIOS configuration level, try
-disabling it.
-
-* if you do not have this option at BIOS configuration level, it does
-not necessarily mean that there is no support for it, thus no
-potential for high latencies; this support might just be forcibly
-enabled at boot time. To solve this, in case your machine has some USB
-controller hardware, make sure to enable the corresponding host
-controller driver support in your kernel configuration. For instance,
-UHCI-compliant hardware needs +CONFIG_USB_UHCI_HCD+. As part of its
-init chores, the driver should reset the host controller properly,
-kicking out the BIOS off the concerned hardware, and deactivate the
-USB legacy mode if set in the same move.
-
-* if you observe high latencies while running X-window, try disabling
-  hardware acceleration in the X-window server file; in the +Device+
-  section of '/etc/X11/XF86Config-4' add the following line:
-
--------------------------------------------------------------------------------
-       Option "NoAccel"
--------------------------------------------------------------------------------
-
-
-[[arm-tsc]]
-ARM tsc emulation issues
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-In order to allow applications to measure short durations with as
-little overhead as possible, Xenomai uses a 64 bits high resolution
-counter. On x86, the counter used for this purpose is the time-stamp
-counter, with its "rdtsc" instruction.
-
-ARM processors generally do not have a 64 bits high resolution counter
-available in user-space, so this counter is emulated by reading
-whatever high resolution counter is available on the processor, and
-used as clock source in kernel-space, and extend it to 64 bits by
-using data shared with the kernel. If Xenomai libraries are compiled
-without emulated tsc support, system calls are used, which have a much
-higher overhead than the emulated tsc code.
-
-In recent versions of the I-pipe patch, SOCs generally select the
-+CONFIG_IPIPE_ARM_KUSER_TSC+ option, which means that the code for
-reading this counter is provided by the kernel at a predetermined
-address (in the vector page, a page which is mapped at the same
-address in every process) and is the code used if you do not pass the
-+--enable-arm-tsc+ or +--disable-arm-tsc+ option to configure, or pass
-+--enable-arm-tsc=kuser+.
-
-This default should be fine with recent patches and most ARM
-SOCs.
-
-However, if you see the following message:
--------------------------------------------------------------------------------
-Xenomai: incompatible feature set
-(userland requires "kuser_tsc...", kernel provides..., missing="kuser_tsc")
--------------------------------------------------------------------------------
-
-It means that you are either using an old patch, or that the SOC you
-are using does not select the +CONFIG_IPIPE_ARM_KUSER_TSC+ option (to
-this date the only in-tree SOC family not using this option is
-ixp4xx).
-
-So you should resort to what Xenomai did before branch 2.6: select the
-tsc emulation code when compiling Xenomai user-space support by using
-the +--enable-arm-tsc+ option. The parameter passed to this option is
-the name of the SOC or SOC family for which you are compiling Xenomai.
-Typing:
--------------------------------------------------------------------------------
-/patch/to/xenomai/configure --help
--------------------------------------------------------------------------------
-
-will return the list of valid values for this option.
-
-If after having enabled this option and recompiled, you see the
-following message when starting the latency test:
--------------------------------------------------------------------------------
-Xenomai: kernel/user tsc emulation mismatch
--------------------------------------------------------------------------------
-
-or
-
--------------------------------------------------------------------------------
-Hardware tsc is not a fast wrapping one
--------------------------------------------------------------------------------
-
-It means that you selected the wrong SOC or SOC family, reconfigure
-Xenomai user-space support by passing the right parameter to
-+--enable-arm-tsc+ and recompile.
-
-The following message:
--------------------------------------------------------------------------------
-Xenomai: Your board/configuration does not allow tsc emulation
--------------------------------------------------------------------------------
-
-means that the kernel-space support for the SOC you are using does not
-provide support for tsc emulation in user-space. In that case, you
-should recompile Xenomai user-space support passing the
-+--disable-arm-tsc+ option.
-
-
-switchtest fails with "pthread_create: Resource temporarily unavailable"
-------------------------------------------------------------------------
-
-The switchtest test creates many kernel threads, this means that the
-option +CONFIG_XENO_OPT_SYS_HEAPSZ+ should be set to large enough
-values. Try increasing it and recompiling.
-
-
-Problem with my code (not Xenomai code)
----------------------------------------
-
-
-"Warning: <service> is deprecated" while compiling kernel code
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Where <service> is a thread creation service, one of:
-
-* +cre_tsk+
-* +pthread_create+
-* +rt_task_create+
-* +sc_tecreate+ or +sc_tcreate+
-* +taskSpawn+ or +taskInit+
-* +t_create+
-
-Starting with Xenomai 3, the skins will not export their interface
-to kernel modules anymore, at the notable exception of the RTDM device
-driver API, which by essence must be used from kernel space for
-writing real-time device drivers. Those warnings are there to remind
-you that application code should run in user-space context instead.
-
-The reason for this is fully explained in the project Roadmap
-document, see
-http://www.xenomai.org/index.php/Xenomai:Roadmap#What_Will_Change_With_Xenomai_3["What
 Will Change With Xenomai 3"].
-
-You may switch those warnings off by enabling the
-+CONFIG_XENO_OPT_NOWARN_DEPRECATED+ option in your kernel configuration,
-but nevertheless, you have been *WARNED*.
-
-
-High latencies when transitioning from primary to secondary mode
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Such transition requires to wake up the Linux task underlying your
-real-time thread when running in secondary mode, since the latter
-needs to leave the Xenomai domain for executing under the control of the
-regular Linux scheduler. Therefore, it all depends on the Linux kernel
-granularity, i.e. its ability to reach the next rescheduling point as
-soon as such wakeup has been requested. Additionally, the task wakeup
-request is performed from a virtual interrupt handler which has to be
-run from the Linux domain upon request from the Xenomai domain, so the
-time required to handle and dispatch this interrupt outside of any
-critical kernel section also needs to be accounted for. Even if the
-kernel granularity improves at each new release, there are still a few
-catches:
-
-* Although the use of DMA might induce additional interrupt latency
-due to bus bandwidth saturation, disabling it for disk I/O is a bad
-idea when using mixed real-time modes. This is due to the fact that
-using PIO often leads to lengthy non-preemptible sections of kernel
-code being run from e.g. IDE drivers, from which pending real-time
-mode transitions could be delayed. In the same vein, make sure that
-your IDE driver runs in unmasked IRQ mode. In any case, a quick check
-using the "hdparm" tool will help:
-
--------------------------------------------------------------------------------
-# hdparm -v /dev/hda
-
-/dev/hda:
- ...
- unmaskirq    =  1 (on)
- using_dma    =  1 (on)
- ...
--------------------------------------------------------------------------------
-
-* Even if your application does not directly request disk I/O, remember
-that the kernel routinely performs housekeeping duties which do, like
-filesystem journal updates or VM commits to the backing store, so
-latencies due to improper disk settings may well trigger apparently
-randomly. Of course, if your application only operates in primary mode
-during all of its time critical duties, i.e. never request Linux
-syscalls, it will not be adversely affected by DMA deactivation or IDE
-masking, since it will remain in the Xenomai domain, and activities from
-such domain can preempt any activity from the Linux domain, including
-disk drivers.
-
-
-Any Xenomai service fails with code -38 (ENOSYS)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Possible reasons for this error are:
-
-* you booted a kernel without Xenomai or I-pipe support, a kernel with
-I-pipe and Xenomai support should have a '/proc/ipipe/version' and
-'/proc/xenomai/version' files;
-
-* the kernel you booted does not have the +CONFIG_XENO_SKIN_*+ option
-enabled for the skin you use, or +CONFIG_XENO_OPT_PERVASIVE+ is
-disabled;
-
-* Xenomai failed to start, check the <<kerror,"Xenomai or I-pipe error
-in the kernel log">> section;
-
-* you are trying to run Xenomai user-space support compiled for x86_32
-on an x86_64 kernel.
-
-
-My application reserves a lot of memory
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Your user-space application unexpectedly reserves a lot of virtual
-memory, as reported by "+top+" or '/proc/<pid>/maps'. Sometimes OOM
-situations even appear during runtime on systems with limited memory.
-
-The Xenomai tasks are underlaid by native POSIX threads, for which a
-huge default amount of stack space memory is reserved by the native
-POSIX support, usually 8MiB per thread, so the overall allocated space
-is about 8MiB{nbsp}*{nbsp}+nr_threads+, which are likely to be locked
-using the +mlockall()+ service, which in turn even commits such space
-to RAM.
-
-Unfortunately, this behaviour cannot be controlled by the
-"+stacksize+" parameter passed to the various thread creation
-routines, i.e. the latter is about limiting the addressable stack
-space on a per-thread basis, but does not affect the amount of stack
-memory initially reserved by the POSIX library.  A work-around
-consists of setting a lower user-limit for initial stack allocation,
-like calling:
-
---------------------------------------------------------------------------------
-ulimit -s <initial-size-in-kbytes>
---------------------------------------------------------------------------------
-
-in your parent shell before running your application (defaults to
-8192).


_______________________________________________
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

Reply via email to