[Xenomai-help] Problems running testsuite

[Xenomai-help] Problems running testsuite

[Tobias Marschall]

Hallo,

I've been using rtai until now and decided to give xenomai (release 2.1) a 
try. I followed the instructions from README.INSTALL, and everything (kernel 
patching, compilation, etc.) went fine. Then I tried to run the latency test, 
which failed:

-----------
/usr/xenomai/testsuite/latency $ ./run
head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
future
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
/usr/xenomai/bin/xeno-load: line 178:  5936 Killed                  $suflag $* 
$cmdargs
-----------

The same for "switch", the same if I call ./latency directly.

Is it correct that the xeno_timerbench module is required for the latency 
test? I get the same result wheter or not I load the module.

What am I doing wrong?

Thanks in advance and best regards,
Tobias

Some (hopefully useful) information follows:
-----------
/usr/xenomai/bin $ ./xeno-info
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux tobi 2.6.14 #3 PREEMPT Thu Apr 13 09:13:53 CEST 2006 i686 AMD Athlon(tm) 
XP 1600+ AuthenticAMD GNU/Linux

Gnu C                  3.3.6
Gnu make               3.80
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.1
e2fsprogs              1.38
Linux C Library        2.3.5
head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
future
Dynamic linker (ldd)   2.3.5
Procps                 3.2.5
Net-tools              1.60
Kbd                    1.12
Sh-utils               5.2.1
Modules Loaded         xeno_timerbench
-----------
~ $ dmesg|grep -i xenomai
I-pipe: Domain Xenomai registered.
Xenomai: hal/x86 started.
Xenomai: real-time nucleus v2.1 (Champagne) loaded.
Xenomai: starting native API services.
Xenomai: starting RTDM services.
-----------
/usr/src/linux $ grep -3i xeno .config
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
# CONFIG_XENO_OPT_WATCHDOG is not set

#
# Timing
#
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_PERIOD=0
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set

#
# Shared interrupts
#
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set

#
# Machine
#
CONFIG_XENO_HW_FPU=y

#
# NMI watchdog
#
# CONFIG_XENO_HW_NMI_DEBUG_LATENCY is not set

#
# SMI workaround
#
# CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
CONFIG_XENO_HW_SMI_DETECT=y
# CONFIG_XENO_HW_SMI_WORKAROUND is not set

#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=m
CONFIG_XENO_SKIN_PSOS=m
CONFIG_XENO_SKIN_UITRON=m
CONFIG_XENO_SKIN_VRTX=m
CONFIG_XENO_SKIN_VXWORKS=m
CONFIG_XENO_SKIN_RTAI=m
CONFIG_XENO_OPT_RTAI_FIFO=y
CONFIG_XENO_OPT_RTAI_SEM=y
CONFIG_XENO_OPT_RTAI_SHM=y
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_SKIN_UVM=m

#
# Drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
CONFIG_XENO_DRIVERS_TIMERBENCH=m
-----------
/usr/xenomai/bin $ ./xeno-test
running ./xeno-test

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) XP 1600+
stepping        : 2
cpu MHz         : 1400.291
cache size      : 256 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 2804.44


Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/meminfo
MemTotal:       774728 kB
MemFree:        744832 kB
Buffers:          3000 kB
Cached:          12284 kB
SwapCached:          0 kB
Active:          11200 kB
Inactive:         6328 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       774728 kB
LowFree:        744832 kB
SwapTotal:     1959920 kB
SwapFree:      1959920 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:           4804 kB
Slab:             8512 kB
CommitLimit:   2347284 kB
Committed_AS:     8200 kB
PageTables:        196 kB
VmallocTotal:   253924 kB
VmallocUsed:      2100 kB
VmallocChunk:   251804 kB

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/ipipe/Linux
Priority=100, Id=0x00000000
irq0-15: accepted
irq16-206: passed
irq207-208: accepted
irq209-212: passed
irq213-216: accepted
irq217-221: passed
irq222-223: accepted
irq224-225: grabbed, virtual
irq226: passed, virtual

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/ipipe/Xenomai
Priority=200, Id=0x58454e4f
irq0-215: passed
irq216: grabbed
irq217-223: passed
irq224-225: passed, virtual
irq226: grabbed, virtual

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/ipipe/version
1.2-01

Thu Apr 13 09:37:38 CEST 2006
running: generate_loads 1
dd workload started, pids 5785

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/interrupts
           CPU0
  0:     169640          XT-PIC  timer, rthal_broadcast_timer
  1:          8          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  9:          0          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
 11:       1956          XT-PIC  eth0
 12:        127          XT-PIC  i8042
 14:       1246          XT-PIC  ide0
 15:         16          XT-PIC  ide1
NMI:          0
LOC:     169605
ERR:          2

Thu Apr 13 09:37:38 CEST 2006
running: cat /proc/loadavg
0.16 0.03 0.01 2/33 5789
head: `-13' option is obsolete; use `-n 13' since this will be removed in the 
future

Thu Apr 13 09:37:38 CEST 2006
running: top -bn1c
top - 09:37:39 up 11 min,  1 user,  load average: 0.16, 0.03, 0.01
Tasks:  35 total,   2 running,  33 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.8% us,  0.8% sy,  0.0% ni, 97.4% id,  1.1% wa,  0.0% hi,  0.0% si
Mem:    774728k total,    30400k used,   744328k free,     3008k buffers
Swap:  1959920k total,        0k used,  1959920k free,    12344k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5785 root      25   0  1464  356  292 R 98.4  0.0   0:00.63 dd if /dev/zero 
of /dev/null
    1 root      16   0  1460  488  428 S  0.0  0.1   0:00.06 init [3]
    2 root      39  19     0    0    0 S  0.0  0.0   0:00.00 [ksoftirqd/0]

Thu Apr 13 09:37:39 CEST 2006
running: ./run -- -q -s -T 10 -t0
head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
future
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
/usr/xenomai/bin/xeno-load: line 178:  5865 Killed                  $suflag $* 
$cmdargs

Thu Apr 13 09:37:40 CEST 2006
running: ./run -- -q -s -T 10 -t1
head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
future
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel periodic task
== All results in microseconds
/usr/xenomai/bin/xeno-load: line 178:  5944 Killed                  $suflag $* 
$cmdargs

Thu Apr 13 09:37:41 CEST 2006
running: ./run -- -q -s -T 10 -t2
head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
future
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
latency: failed to open benchmark device, code -16
(modprobe xeno_timerbench?)

Thu Apr 13 09:37:42 CEST 2006
running: cat /proc/interrupts
           CPU0
  0:     170509          XT-PIC  timer, rthal_broadcast_timer
  1:          8          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  9:          0          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
 11:       2055          XT-PIC  eth0
 12:        127          XT-PIC  i8042
 14:       1260          XT-PIC  ide0
 15:         16          XT-PIC  ide1
NMI:          0
LOC:     170474
ERR:          2

Thu Apr 13 09:37:42 CEST 2006
running: cat /proc/loadavg
0.16 0.03 0.01 4/33 6033
head: `-13' option is obsolete; use `-n 13' since this will be removed in the 
future

Thu Apr 13 09:37:42 CEST 2006
running: top -bn1c
top - 09:37:42 up 11 min,  1 user,  load average: 0.16, 0.03, 0.01
Tasks:  35 total,   2 running,  33 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0% us,  1.1% sy,  0.0% ni, 96.9% id,  1.1% wa,  0.0% hi,  0.0% si
Mem:    774728k total,    30556k used,   744172k free,     3044k buffers
Swap:  1959920k total,        0k used,  1959920k free,    12344k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5785 root      25   0  1464  356  292 R 98.9  0.0   0:03.70 dd if /dev/zero 
of /dev/null
    1 root      19   0  1460  488  428 S  0.0  0.1   0:00.06 init [3]
    2 root      39  19     0    0    0 S  0.0  0.0   0:00.00 [ksoftirqd/0]

Re: [Xenomai-help] Problems running testsuite

[Jim Cromie]

[-- Attachment #1: Type: text/plain, Size: 4069 bytes --]

Tobias Marschall wrote:
> Hallo,
>
> I've been using rtai until now and decided to give xenomai (release 2.1) a 
> try. I followed the instructions from README.INSTALL, and everything (kernel 
> patching, compilation, etc.) went fine. Then I tried to run the latency test, 
> which failed:
>
> -----------
> /usr/xenomai/testsuite/latency $ ./run
> head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>   

this particular error is patched, attached.





> future
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> /usr/xenomai/bin/xeno-load: line 178:  5936 Killed                  $suflag $* 
> $cmdargs
> -----------
>
> The same for "switch", the same if I call ./latency directly.
>
> Is it correct that the xeno_timerbench module is required for the latency 
> test? 
I believe that it (timerbench) is only needed for latency -t2, ICBW.
I built it as a module

> I get the same result wheter or not I load the module.
>
>   

Ive seen that Killed line before - but its been a while, I have no 
recollection...

have you tried 'run -- ' ?
the double dash insures that the following args are passed thru the script,
(so its very unlikely to matter here, but you never know ..)


heres a chunk from xeno-test on my box.
Obviously it didnt work for you, but you can re-try the running line,
see if its different than what youre currently getting.


Mon Apr 10 14:58:26 PDT 2006
running: ./run -- -T 120 -h -s -l 30 -t0
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|      24.499|      40.854|      58.042|       0|      24.499|      
58.042
RTD|      24.746|      40.783|      57.502|       0|      24.499|      
58.042
RTD|      24.353|      40.768|      57.772|       0|      24.353|      
58.042



> What am I doing wrong?
>
>   
dunno, but I hope this is helpful til you get better answers.


> Thanks in advance and best regards,
> Tobias
>
> Some (hopefully useful) information follows:
> -----------
> /usr/xenomai/bin $ ./xeno-info
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux tobi 2.6.14 #3 PREEMPT Thu Apr 13 09:13:53 CEST 2006 i686 AMD Athlon(tm) 
> XP 1600+ AuthenticAMD GNU/Linux
>
> Gnu C                  3.3.6
> Gnu make               3.80
> util-linux             2.12r
> mount                  2.12r
> module-init-tools      3.2.1
> e2fsprogs              1.38
> Linux C Library        2.3.5
> head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
> future
> Dynamic linker (ldd)   2.3.5
> Procps                 3.2.5
> Net-tools              1.60
> Kbd                    1.12
> Sh-utils               5.2.1
> Modules Loaded         xeno_timerbench
> -----------
> ~ $ dmesg|grep -i xenomai
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/x86 started.
> Xenomai: real-time nucleus v2.1 (Champagne) loaded.
> Xenomai: starting native API services.
> Xenomai: starting RTDM services.
>   

> -----------
> /usr/src/linux $ grep -3i xeno .config
> #
>   
FWIW, if you enable
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
then the xeno-test script will run that grep (ie zgrep XENO 
/proc/config.gz) for you.

there are a few additions that might be worthwhile -

 zegrep -E '^CONFIG_M|PREEMPT' pc-3/.config
CONFIG_MMU=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_M586MMX=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_MICROCODE=m
CONFIG_MII=y
CONFIG_MSDOS_FS=m
CONFIG_MSDOS_PARTITION=y
CONFIG_MAGIC_SYSRQ=y

I havent made them, the CONFIG_M picks up the Machine, but is perhaps 
too noisy.
THen again, MMU an MODULE_* info is useful.

[-- Attachment #2: patch-head-n --]
[-- Type: text/plain, Size: 412 bytes --]

Index: scripts/xeno-test.in
===================================================================
--- scripts/xeno-test.in	(revision 924)
+++ scripts/xeno-test.in	(working copy)
@@ -90,7 +90,7 @@
     loudly cat /proc/interrupts
     loudly cat /proc/loadavg
     [ -n "$prepost" ] && loudly $prepost
-    loudly top -bn1c | head -$(( 12 + $workload ))
+    loudly top -bn1c | head -n $(( 12 + $workload ))
 }
 
 

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

Jim Cromie wrote:
> Tobias Marschall wrote:
> 
>> Hallo,
>>
>> I've been using rtai until now and decided to give xenomai (release 
>> 2.1) a try. I followed the instructions from README.INSTALL, and 
>> everything (kernel patching, compilation, etc.) went fine. Then I 
>> tried to run the latency test, which failed:
>>
>> -----------
>> /usr/xenomai/testsuite/latency $ ./run
>> head: `-1' option is obsolete; use `-n 1' since this will be removed 
>> in the   
> 
> 
> this particular error is patched, attached.
> 

Applied, Thanks.

-- 

Philippe.

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Jim Cromie wrote:
> Tobias Marschall wrote:
> 
>> Hallo,
>>
>> I've been using rtai until now and decided to give xenomai (release 
>> 2.1) a try. I followed the instructions from README.INSTALL, and 
>> everything (kernel patching, compilation, etc.) went fine. Then I 
>> tried to run the latency test, which failed:
>>
>> -----------
>> /usr/xenomai/testsuite/latency $ ./run
>> head: `-1' option is obsolete; use `-n 1' since this will be removed 
>> in the   
> 
> 
> this particular error is patched, attached.

While I was at it, I've fixed other spots in the same vein, in other 
scripts. This patch applies against v2.1.0.

-- 

Philippe.

[-- Attachment #2: fix-head-obsolete-syntax.patch --]
[-- Type: text/x-patch, Size: 1660 bytes --]

Index: scripts/xeno-info
===================================================================
--- scripts/xeno-info	(revision 924)
+++ scripts/xeno-info	(working copy)
@@ -54,7 +54,7 @@
 -e 's/\.so$//' | awk -F'[.-]'   '{print "Linux C Library        " \
 $(NF-2)"."$(NF-1)"."$NF}'
 
-ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1 | awk \
+ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -n1 | awk \
 'NR==1{print "Dynamic linker (ldd)  ", $NF}'
 
 ls -l /usr/lib/lib{g,stdc}++.so  2>/dev/null | awk -F. \
Index: scripts/prepare-kernel.sh
===================================================================
--- scripts/prepare-kernel.sh	(revision 924)
+++ scripts/prepare-kernel.sh	(working copy)
@@ -321,7 +321,7 @@
    exit 2
 else
    if test x$adeos_patch = x; then
-      default_adeos_patch=`( ls $xenomai_root/ksrc/arch/$xenomai_arch/patches/adeos-ipipe-$linux_VERSION.$linux_PATCHLEVEL*|sort -r ) 2>/dev/null | head -1`
+      default_adeos_patch=`( ls $xenomai_root/ksrc/arch/$xenomai_arch/patches/adeos-ipipe-$linux_VERSION.$linux_PATCHLEVEL*|sort -r ) 2>/dev/null | head -n1`
    fi
    if test x$default_adeos_patch = x; then
       default_adeos_patch=/dev/null
Index: scripts/xeno-load.in
===================================================================
--- scripts/xeno-load.in	(revision 924)
+++ scripts/xeno-load.in	(working copy)
@@ -56,7 +56,7 @@
 fi
 
 if test $target_name = default; then
-  target_name=`cut -s -d: -f1 $run_info_file | head -1`
+  target_name=`cut -s -d: -f1 $run_info_file | head -n1`
   if test "x$target_name" = x; then
      echo "xeno-load: no target defined in $run_info_file"
      exit 2

Re: [Xenomai-help] Problems running testsuite

[Scott Biddlestone]

I saw a similar error when using --enable-x86-sep and not having NPTL 
enabled in glibc.
Try configuring without --enable-x86-sep (used in the README.INSTALL 
Pentium x86 example, the default is disabled).

-Scott Biddlestone

Tobias Marschall wrote:

>Hallo,
>
>I've been using rtai until now and decided to give xenomai (release 2.1) a 
>try. I followed the instructions from README.INSTALL, and everything (kernel 
>patching, compilation, etc.) went fine. Then I tried to run the latency test, 
>which failed:
>
>-----------
>/usr/xenomai/testsuite/latency $ ./run
>head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>future
>*
>*
>* Type ^C to stop this application.
>*
>*
>== Sampling period: 100 us
>== Test mode: periodic user-mode task
>== All results in microseconds
>/usr/xenomai/bin/xeno-load: line 178:  5936 Killed                  $suflag $* 
>$cmdargs
>-----------
>
>The same for "switch", the same if I call ./latency directly.
>
>Is it correct that the xeno_timerbench module is required for the latency 
>test? I get the same result wheter or not I load the module.
>
>What am I doing wrong?
>
>Thanks in advance and best regards,
>Tobias
>
>Some (hopefully useful) information follows:
>-----------
>/usr/xenomai/bin $ ./xeno-info
>If some fields are empty or look unusual you may have an old version.
>Compare to the current minimal requirements in Documentation/Changes.
>
>Linux tobi 2.6.14 #3 PREEMPT Thu Apr 13 09:13:53 CEST 2006 i686 AMD Athlon(tm) 
>XP 1600+ AuthenticAMD GNU/Linux
>
>Gnu C                  3.3.6
>Gnu make               3.80
>util-linux             2.12r
>mount                  2.12r
>module-init-tools      3.2.1
>e2fsprogs              1.38
>Linux C Library        2.3.5
>head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>future
>Dynamic linker (ldd)   2.3.5
>Procps                 3.2.5
>Net-tools              1.60
>Kbd                    1.12
>Sh-utils               5.2.1
>Modules Loaded         xeno_timerbench
>-----------
>~ $ dmesg|grep -i xenomai
>I-pipe: Domain Xenomai registered.
>Xenomai: hal/x86 started.
>Xenomai: real-time nucleus v2.1 (Champagne) loaded.
>Xenomai: starting native API services.
>Xenomai: starting RTDM services.
>-----------
>/usr/src/linux $ grep -3i xeno .config
>#
># Real-time sub-system
>#
>CONFIG_XENOMAI=y
>CONFIG_XENO_OPT_NUCLEUS=y
>CONFIG_XENO_OPT_PERVASIVE=y
>CONFIG_XENO_OPT_PIPE=y
>CONFIG_XENO_OPT_PIPE_NRDEV=32
>CONFIG_XENO_OPT_REGISTRY=y
>CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
>CONFIG_XENO_OPT_SYS_HEAPSZ=128
># CONFIG_XENO_OPT_ISHIELD is not set
>CONFIG_XENO_OPT_STATS=y
># CONFIG_XENO_OPT_DEBUG is not set
># CONFIG_XENO_OPT_WATCHDOG is not set
>
>#
># Timing
>#
>CONFIG_XENO_OPT_TIMING_PERIODIC=y
>CONFIG_XENO_OPT_TIMING_PERIOD=0
>CONFIG_XENO_OPT_TIMING_TIMERLAT=0
>CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
>
>#
># Scalability
>#
># CONFIG_XENO_OPT_SCALABLE_SCHED is not set
>CONFIG_XENO_OPT_TIMER_LIST=y
># CONFIG_XENO_OPT_TIMER_HEAP is not set
>
>#
># Shared interrupts
>#
># CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
># CONFIG_XENO_OPT_SHIRQ_EDGE is not set
>
>#
># Machine
>#
>CONFIG_XENO_HW_FPU=y
>
>#
># NMI watchdog
>#
># CONFIG_XENO_HW_NMI_DEBUG_LATENCY is not set
>
>#
># SMI workaround
>#
># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
>CONFIG_XENO_HW_SMI_DETECT=y
># CONFIG_XENO_HW_SMI_WORKAROUND is not set
>
>#
># Interfaces
>#
>CONFIG_XENO_SKIN_NATIVE=y
>CONFIG_XENO_OPT_NATIVE_PIPE=y
>CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>CONFIG_XENO_OPT_NATIVE_SEM=y
>CONFIG_XENO_OPT_NATIVE_EVENT=y
>CONFIG_XENO_OPT_NATIVE_MUTEX=y
>CONFIG_XENO_OPT_NATIVE_COND=y
>CONFIG_XENO_OPT_NATIVE_QUEUE=y
>CONFIG_XENO_OPT_NATIVE_HEAP=y
>CONFIG_XENO_OPT_NATIVE_ALARM=y
>CONFIG_XENO_OPT_NATIVE_MPS=y
># CONFIG_XENO_OPT_NATIVE_INTR is not set
>CONFIG_XENO_SKIN_POSIX=m
>CONFIG_XENO_SKIN_PSOS=m
>CONFIG_XENO_SKIN_UITRON=m
>CONFIG_XENO_SKIN_VRTX=m
>CONFIG_XENO_SKIN_VXWORKS=m
>CONFIG_XENO_SKIN_RTAI=m
>CONFIG_XENO_OPT_RTAI_FIFO=y
>CONFIG_XENO_OPT_RTAI_SEM=y
>CONFIG_XENO_OPT_RTAI_SHM=y
>CONFIG_XENO_SKIN_RTDM=y
>CONFIG_XENO_SKIN_UVM=m
>
>#
># Drivers
>#
># CONFIG_XENO_DRIVERS_16550A is not set
>CONFIG_XENO_DRIVERS_TIMERBENCH=m
>-----------
>/usr/xenomai/bin $ ./xeno-test
>running ./xeno-test
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/cpuinfo
>processor       : 0
>vendor_id       : AuthenticAMD
>cpu family      : 6
>model           : 6
>model name      : AMD Athlon(tm) XP 1600+
>stepping        : 2
>cpu MHz         : 1400.291
>cache size      : 256 KB
>fpu             : yes
>fpu_exception   : yes
>cpuid level     : 1
>flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
>cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
>bogomips        : 2804.44
>
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/meminfo
>MemTotal:       774728 kB
>MemFree:        744832 kB
>Buffers:          3000 kB
>Cached:          12284 kB
>SwapCached:          0 kB
>Active:          11200 kB
>Inactive:         6328 kB
>HighTotal:           0 kB
>HighFree:            0 kB
>LowTotal:       774728 kB
>LowFree:        744832 kB
>SwapTotal:     1959920 kB
>SwapFree:      1959920 kB
>Dirty:               0 kB
>Writeback:           0 kB
>Mapped:           4804 kB
>Slab:             8512 kB
>CommitLimit:   2347284 kB
>Committed_AS:     8200 kB
>PageTables:        196 kB
>VmallocTotal:   253924 kB
>VmallocUsed:      2100 kB
>VmallocChunk:   251804 kB
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/ipipe/Linux
>Priority=100, Id=0x00000000
>irq0-15: accepted
>irq16-206: passed
>irq207-208: accepted
>irq209-212: passed
>irq213-216: accepted
>irq217-221: passed
>irq222-223: accepted
>irq224-225: grabbed, virtual
>irq226: passed, virtual
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/ipipe/Xenomai
>Priority=200, Id=0x58454e4f
>irq0-215: passed
>irq216: grabbed
>irq217-223: passed
>irq224-225: passed, virtual
>irq226: grabbed, virtual
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/ipipe/version
>1.2-01
>
>Thu Apr 13 09:37:38 CEST 2006
>running: generate_loads 1
>dd workload started, pids 5785
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/interrupts
>           CPU0
>  0:     169640          XT-PIC  timer, rthal_broadcast_timer
>  1:          8          XT-PIC  i8042
>  2:          0          XT-PIC  cascade
>  9:          0          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> 11:       1956          XT-PIC  eth0
> 12:        127          XT-PIC  i8042
> 14:       1246          XT-PIC  ide0
> 15:         16          XT-PIC  ide1
>NMI:          0
>LOC:     169605
>ERR:          2
>
>Thu Apr 13 09:37:38 CEST 2006
>running: cat /proc/loadavg
>0.16 0.03 0.01 2/33 5789
>head: `-13' option is obsolete; use `-n 13' since this will be removed in the 
>future
>
>Thu Apr 13 09:37:38 CEST 2006
>running: top -bn1c
>top - 09:37:39 up 11 min,  1 user,  load average: 0.16, 0.03, 0.01
>Tasks:  35 total,   2 running,  33 sleeping,   0 stopped,   0 zombie
>Cpu(s):  0.8% us,  0.8% sy,  0.0% ni, 97.4% id,  1.1% wa,  0.0% hi,  0.0% si
>Mem:    774728k total,    30400k used,   744328k free,     3008k buffers
>Swap:  1959920k total,        0k used,  1959920k free,    12344k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 5785 root      25   0  1464  356  292 R 98.4  0.0   0:00.63 dd if /dev/zero 
>of /dev/null
>    1 root      16   0  1460  488  428 S  0.0  0.1   0:00.06 init [3]
>    2 root      39  19     0    0    0 S  0.0  0.0   0:00.00 [ksoftirqd/0]
>
>Thu Apr 13 09:37:39 CEST 2006
>running: ./run -- -q -s -T 10 -t0
>head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>future
>*
>*
>* Type ^C to stop this application.
>*
>*
>== Sampling period: 100 us
>== Test mode: periodic user-mode task
>== All results in microseconds
>/usr/xenomai/bin/xeno-load: line 178:  5865 Killed                  $suflag $* 
>$cmdargs
>
>Thu Apr 13 09:37:40 CEST 2006
>running: ./run -- -q -s -T 10 -t1
>head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>future
>*
>*
>* Type ^C to stop this application.
>*
>*
>== Sampling period: 100 us
>== Test mode: in-kernel periodic task
>== All results in microseconds
>/usr/xenomai/bin/xeno-load: line 178:  5944 Killed                  $suflag $* 
>$cmdargs
>
>Thu Apr 13 09:37:41 CEST 2006
>running: ./run -- -q -s -T 10 -t2
>head: `-1' option is obsolete; use `-n 1' since this will be removed in the 
>future
>*
>*
>* Type ^C to stop this application.
>*
>*
>== Sampling period: 100 us
>== Test mode: in-kernel timer handler
>== All results in microseconds
>latency: failed to open benchmark device, code -16
>(modprobe xeno_timerbench?)
>
>Thu Apr 13 09:37:42 CEST 2006
>running: cat /proc/interrupts
>           CPU0
>  0:     170509          XT-PIC  timer, rthal_broadcast_timer
>  1:          8          XT-PIC  i8042
>  2:          0          XT-PIC  cascade
>  9:          0          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> 11:       2055          XT-PIC  eth0
> 12:        127          XT-PIC  i8042
> 14:       1260          XT-PIC  ide0
> 15:         16          XT-PIC  ide1
>NMI:          0
>LOC:     170474
>ERR:          2
>
>Thu Apr 13 09:37:42 CEST 2006
>running: cat /proc/loadavg
>0.16 0.03 0.01 4/33 6033
>head: `-13' option is obsolete; use `-n 13' since this will be removed in the 
>future
>
>Thu Apr 13 09:37:42 CEST 2006
>running: top -bn1c
>top - 09:37:42 up 11 min,  1 user,  load average: 0.16, 0.03, 0.01
>Tasks:  35 total,   2 running,  33 sleeping,   0 stopped,   0 zombie
>Cpu(s):  1.0% us,  1.1% sy,  0.0% ni, 96.9% id,  1.1% wa,  0.0% hi,  0.0% si
>Mem:    774728k total,    30556k used,   744172k free,     3044k buffers
>Swap:  1959920k total,        0k used,  1959920k free,    12344k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 5785 root      25   0  1464  356  292 R 98.9  0.0   0:03.70 dd if /dev/zero 
>of /dev/null
>    1 root      19   0  1460  488  428 S  0.0  0.1   0:00.06 init [3]
>    2 root      39  19     0    0    0 S  0.0  0.0   0:00.00 [ksoftirqd/0]
>
>_______________________________________________
>Xenomai-help mailing list
>Xenomai-help@domain.hid
>https://mail.gna.org/listinfo/xenomai-help
>
>  
>

Re: [Xenomai-help] Problems running testsuite

[Tobias Marschall]

Hello,

On Thursday 13 April 2006 21:00, you wrote:
> I saw a similar error when using --enable-x86-sep and not having NPTL
> enabled in glibc.
> Try configuring without --enable-x86-sep (used in the README.INSTALL
> Pentium x86 example, the default is disabled).
that did the trick, thank you for the hint! I did check that the cpu supported 
the sep instruction, but I wasn't aware that NPTL is required in this case.

Mentioning this in README.INSTALL would be helpful. I wonder if that mistake 
could be caught by configure. 

Regards,
Tobias

> Tobias Marschall wrote:
> >Hallo,
> >
> >I've been using rtai until now and decided to give xenomai (release 2.1) a
> >try. I followed the instructions from README.INSTALL, and everything
> > (kernel patching, compilation, etc.) went fine. Then I tried to run the
> > latency test, which failed:
> >
> >-----------
> >/usr/xenomai/testsuite/latency $ ./run
> >head: `-1' option is obsolete; use `-n 1' since this will be removed in
> > the future
> >*
> >*
> >* Type ^C to stop this application.
> >*
> >*
> >== Sampling period: 100 us
> >== Test mode: periodic user-mode task
> >== All results in microseconds
> >/usr/xenomai/bin/xeno-load: line 178:  5936 Killed                 
> > $suflag $* $cmdargs
> >-----------

Re: [Xenomai-help] Problems running testsuite

[Gilles Chanteperdrix]

Tobias Marschall wrote:
 > Hello,
 > 
 > On Thursday 13 April 2006 21:00, you wrote:
 > > I saw a similar error when using --enable-x86-sep and not having NPTL
 > > enabled in glibc.
 > > Try configuring without --enable-x86-sep (used in the README.INSTALL
 > > Pentium x86 example, the default is disabled).
 > that did the trick, thank you for the hint! I did check that the cpu supported 
 > the sep instruction, but I wasn't aware that NPTL is required in this case.
 > 
 > Mentioning this in README.INSTALL would be helpful. I wonder if that mistake 
 > could be caught by configure. 

It could be caught by configure, at least if not cross-compiling, by
running getconf GNU_LIBPTHREAD_VERSION.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Problems running testsuite

[Jim Cromie]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

Gilles Chanteperdrix wrote:
> Tobias Marschall wrote:
>  > Hello,
>  > 
>  > On Thursday 13 April 2006 21:00, you wrote:
>  > > I saw a similar error when using --enable-x86-sep and not having NPTL
>  > > enabled in glibc.
>  > > Try configuring without --enable-x86-sep (used in the README.INSTALL
>  > > Pentium x86 example, the default is disabled).
>  > that did the trick, thank you for the hint! I did check that the cpu supported 
>  > the sep instruction, but I wasn't aware that NPTL is required in this case.
>  > 
>  > Mentioning this in README.INSTALL would be helpful. I wonder if that mistake 
>  > could be caught by configure. 
>
> It could be caught by configure, at least if not cross-compiling, by
> running getconf GNU_LIBPTHREAD_VERSION.
>
>   
ie:
[jimc@domain.hid xenomai]$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.6

doesnt /proc/cpuinfo, flags entry, indicate whether the cpu supports SEP ?

flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2


what x86 processors support --enable-x86-sep ?   
Pentium-4 ?  Xeon ? Athlon ?
my Pentium-M apparently doesnt.



WRT inferring more stuff from the build/host machine, I have some concerns;
I build on my 686 laptop for a smaller/different 586 target.  This is 
not 'cross-compilation',
and could be compromised by too many automatic optimizations.
So, ideally, Id like the potentially troublesome optimizations to be
identified and gated by a prompt.

Maybe we need a script thats run on the target box, that collects
the needed configuration factors; presumably including:
CPUFLAGS=`grep flags /proc/cpuinfo`
NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`


Somewhat related: 
prepare-kernel asks me for target architecture, I started by entering 
i586 explicitly,
but after a while, just took the i686 default.  Ive not noticed anything 
different/wrong,
but would appreciate confirmation/explanation.

thanks
jimc


PS.  attached is an attempt to improve README.INSTALL along these and 
other lines.
Please feel free to cut out the false parts ;-)

[-- Attachment #2: patch-readme --]
[-- Type: text/plain, Size: 1645 bytes --]

Index: README.INSTALL
===================================================================
--- README.INSTALL	(revision 927)
+++ README.INSTALL	(working copy)
@@ -74,6 +74,19 @@
 Once the target kernel has been prepared, all Xenomai configuration
 options are available from the "Real-time subsystem" toplevel menu.
 
+When configuring, you should *disable* PM (power management), ACPI,
+and CPU_FREQ.  The 1st 2 invoke uninterruptible BIOS routines, which
+destroy the rt-determinism guarantees that you're presumably seeking.
+If you're curious, build it, install it, and run xeno-test, you'll
+likely see very large latencies.  If you see otherwise, please email
+the evidence.
+
+CPU_FREQ is bad because it breaks some timing guarantees on some
+chips, and these problems are too varied/unpredictable to accomodate.
+For example, (my) Pentium-M laptop shows "cpu MHz : 600.000" at idle,
+but 1700 when compiling.  Some TSCs also change frequency with the
+processor, making them useless if the clock is changing.
+
 Once configured, the kernel should be built as usual.
 
 It might be a good idea to put all the output into a different build
@@ -143,9 +156,11 @@
 NAME                DESCRIPTION                      [BINDING,]DEFAULT(*)
 
 --enable-x86-sep    Enable x86 SEP instructions      strong,disabled
-                    for issuing syscalls
+                    for issuing syscalls.
+		    You will also need NPTL
 
 --enable-x86-tsc    Enable x86 TSC for timings       strong,enabled
+		    falls back to PIT if needed
 
 --enable-arm-arch   Define version of the target     strong,"4"
                     ARM core architecture

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

Jim Cromie wrote:
> Gilles Chanteperdrix wrote:
> 
>> Tobias Marschall wrote:
>>  > Hello,
>>  >  > On Thursday 13 April 2006 21:00, you wrote:
>>  > > I saw a similar error when using --enable-x86-sep and not having 
>> NPTL
>>  > > enabled in glibc.
>>  > > Try configuring without --enable-x86-sep (used in the README.INSTALL
>>  > > Pentium x86 example, the default is disabled).
>>  > that did the trick, thank you for the hint! I did check that the 
>> cpu supported  > the sep instruction, but I wasn't aware that NPTL is 
>> required in this case.
>>  >  > Mentioning this in README.INSTALL would be helpful. I wonder if 
>> that mistake  > could be caught by configure.
>> It could be caught by configure, at least if not cross-compiling, by
>> running getconf GNU_LIBPTHREAD_VERSION.
>>
>>   
> 
> ie:
> [jimc@domain.hid xenomai]$ getconf GNU_LIBPTHREAD_VERSION
> NPTL 2.3.6
> 
> doesnt /proc/cpuinfo, flags entry, indicate whether the cpu supports SEP ?
> 

It should, yes.

> flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov 
> pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
>

Strange indeed, if that's a recent genuine Intel CPU.

> 
> what x86 processors support --enable-x86-sep ?   Pentium-4 ?  Xeon ? 
> Athlon ?
> my Pentium-M apparently doesnt.

AFAIK, Intel supports sysenter/sysexit since the PII, and AMD introduced 
them with the K7. The genuine Pentium M does support them, no doubt.

> 
> 
> 
> WRT inferring more stuff from the build/host machine, I have some concerns;
> I build on my 686 laptop for a smaller/different 586 target.  This is 
> not 'cross-compilation',
> and could be compromised by too many automatic optimizations.
> So, ideally, Id like the potentially troublesome optimizations to be
> identified and gated by a prompt.
> 
> Maybe we need a script thats run on the target box, that collects
> the needed configuration factors; presumably including:
> CPUFLAGS=`grep flags /proc/cpuinfo`
> NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`
> 

The problem is that we might not always have the target at hand when 
building the user-space support (e.g. LiveCD, deployment distro stuff). 
Therefore it could only be some optional helper, but not part of the 
regular build process.

> 
> Somewhat related: prepare-kernel asks me for target architecture, I 
> started by entering i586 explicitly,
> but after a while, just took the i686 default.  Ive not noticed anything 
> different/wrong,
> but would appreciate confirmation/explanation.
> 

Which information did you look at to determine that it was using the 686 
profile?

> thanks
> jimc
> 
> 
> PS.  attached is an attempt to improve README.INSTALL along these and 
> other lines.
> Please feel free to cut out the false parts ;-)
> 
> 
> ------------------------------------------------------------------------
> 
> Index: README.INSTALL
> ===================================================================
> --- README.INSTALL	(revision 927)
> +++ README.INSTALL	(working copy)
> @@ -74,6 +74,19 @@
>  Once the target kernel has been prepared, all Xenomai configuration
>  options are available from the "Real-time subsystem" toplevel menu.
>  
> +When configuring, you should *disable* PM (power management), ACPI,
> +and CPU_FREQ.  The 1st 2 invoke uninterruptible BIOS routines, which
> +destroy the rt-determinism guarantees that you're presumably seeking.
> +If you're curious, build it, install it, and run xeno-test, you'll
> +likely see very large latencies.  If you see otherwise, please email
> +the evidence.
> +
> +CPU_FREQ is bad because it breaks some timing guarantees on some
> +chips, and these problems are too varied/unpredictable to accomodate.
> +For example, (my) Pentium-M laptop shows "cpu MHz : 600.000" at idle,
> +but 1700 when compiling.  Some TSCs also change frequency with the
> +processor, making them useless if the clock is changing.
> +
>  Once configured, the kernel should be built as usual.
>  
>  It might be a good idea to put all the output into a different build
> @@ -143,9 +156,11 @@
>  NAME                DESCRIPTION                      [BINDING,]DEFAULT(*)
>  
>  --enable-x86-sep    Enable x86 SEP instructions      strong,disabled
> -                    for issuing syscalls
> +                    for issuing syscalls.
> +		    You will also need NPTL
>  
>  --enable-x86-tsc    Enable x86 TSC for timings       strong,enabled
> +		    falls back to PIT if needed
>  
>  --enable-arm-arch   Define version of the target     strong,"4"
>                      ARM core architecture
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

Jim Cromie wrote:
> PS.  attached is an attempt to improve README.INSTALL along these and 
> other lines.
> Please feel free to cut out the false parts ;-)
>

I think we should simply add a link from README.INSTALL to the 
troubleshooting guide, where things are explained in length, for each 
platforms.

> 
> ------------------------------------------------------------------------
> 
> Index: README.INSTALL
> ===================================================================
> --- README.INSTALL	(revision 927)
> +++ README.INSTALL	(working copy)
> @@ -74,6 +74,19 @@
>  Once the target kernel has been prepared, all Xenomai configuration
>  options are available from the "Real-time subsystem" toplevel menu.
>  
> +When configuring, you should *disable* PM (power management), ACPI,
> +and CPU_FREQ.  The 1st 2 invoke uninterruptible BIOS routines, which
> +destroy the rt-determinism guarantees that you're presumably seeking.
> +If you're curious, build it, install it, and run xeno-test, you'll
> +likely see very large latencies.  If you see otherwise, please email
> +the evidence.
> +
> +CPU_FREQ is bad because it breaks some timing guarantees on some
> +chips, and these problems are too varied/unpredictable to accomodate.
> +For example, (my) Pentium-M laptop shows "cpu MHz : 600.000" at idle,
> +but 1700 when compiling.  Some TSCs also change frequency with the
> +processor, making them useless if the clock is changing.
> +
>  Once configured, the kernel should be built as usual.
>  
>  It might be a good idea to put all the output into a different build
> @@ -143,9 +156,11 @@
>  NAME                DESCRIPTION                      [BINDING,]DEFAULT(*)
>  
>  --enable-x86-sep    Enable x86 SEP instructions      strong,disabled
> -                    for issuing syscalls
> +                    for issuing syscalls.
> +		    You will also need NPTL
>  
>  --enable-x86-tsc    Enable x86 TSC for timings       strong,enabled
> +		    falls back to PIT if needed
>  

Nope, the user-space support could not fallback properly to PIT if TSC 
is activated using this switch. In the latter case, "rdtsc" insns will 
be wired into the code, making it invalid for using with CPUs lacking a 
timestamp counter.

-- 

Philippe.

Re: [Xenomai-help] Problems running testsuite

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > > Maybe we need a script thats run on the target box, that collects
 > > the needed configuration factors; presumably including:
 > > CPUFLAGS=`grep flags /proc/cpuinfo`
 > > NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`
 > > 
 > 
 > The problem is that we might not always have the target at hand when 
 > building the user-space support (e.g. LiveCD, deployment distro stuff). 
 > Therefore it could only be some optional helper, but not part of the 
 > regular build process.

Maybe we could modify skins user-space initialization so that they test
whether running NPTL if SEP is enabled ? Here is an example, doing
this in plain C :

https://listman.redhat.com/archives/phil-list/2003-April/msg00036.html

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > > Maybe we need a script thats run on the target box, that collects
>  > > the needed configuration factors; presumably including:
>  > > CPUFLAGS=`grep flags /proc/cpuinfo`
>  > > NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`
>  > > 
>  > 
>  > The problem is that we might not always have the target at hand when 
>  > building the user-space support (e.g. LiveCD, deployment distro stuff). 
>  > Therefore it could only be some optional helper, but not part of the 
>  > regular build process.
> 
> Maybe we could modify skins user-space initialization so that they test
> whether running NPTL if SEP is enabled ? Here is an example, doing
> this in plain C :
> 
> https://listman.redhat.com/archives/phil-list/2003-April/msg00036.html
> 

Looks good. Additionally, we might end up moving common portions of the 
various library constructors into a single file in order to reduce code 
duplication.

-- 

Philippe.

Re: [Xenomai-help] Problems running testsuite

[Jim Cromie]

Philippe Gerum wrote:
> Jim Cromie wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> Tobias Marschall wrote:
>>>  > Hello,
>>>  >  > On Thursday 13 April 2006 21:00, you wrote:
>>>  > > I saw a similar error when using --enable-x86-sep and not 
>>> having NPTL
>>>  > > enabled in glibc.
>>>  > > Try configuring without --enable-x86-sep (used in the 
>>> README.INSTALL
>>>  > > Pentium x86 example, the default is disabled).
>>>  > that did the trick, thank you for the hint! I did check that the 
>>> cpu supported  > the sep instruction, but I wasn't aware that NPTL 
>>> is required in this case.
>>>  >  > Mentioning this in README.INSTALL would be helpful. I wonder 
>>> if that mistake  > could be caught by configure.
>>> It could be caught by configure, at least if not cross-compiling, by
>>> running getconf GNU_LIBPTHREAD_VERSION.
>>>
>>>   
>>
>> ie:
>> [jimc@domain.hid xenomai]$ getconf GNU_LIBPTHREAD_VERSION
>> NPTL 2.3.6
>>
>> doesnt /proc/cpuinfo, flags entry, indicate whether the cpu supports 
>> SEP ?
>>
>
> It should, yes.
>
>> flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca 
>> cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
>>
>
> Strange indeed, if that's a recent genuine Intel CPU.
>

Well, Im not *stoned*, but it clearly looks like I am..
heres the whole thing:

[jimc@domain.hid linux-2.6.16]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.70GHz
stepping        : 6
cpu MHz         : 600.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
bogomips        : 1198.01


very strange.   Ive seen someone elses P-4 cpuinfo, flag is there, 
spelled 'sep'


>>
>> what x86 processors support --enable-x86-sep ?   Pentium-4 ?  Xeon ? 
>> Athlon ?
>> my Pentium-M apparently doesnt.
>
> AFAIK, Intel supports sysenter/sysexit since the PII, and AMD 
> introduced them with the K7. The genuine Pentium M does support them, 
> no doubt.
>
Perhaps I need to email LKML.
What would you expect if I built with --enable-sep (for my laptop) ?
success / illegal-instruction exception / undefined-wierd behavior ?
>>
>>
>>
>> WRT inferring more stuff from the build/host machine, I have some 
>> concerns;
>> I build on my 686 laptop for a smaller/different 586 target.  This is 
>> not 'cross-compilation',
>> and could be compromised by too many automatic optimizations.
>> So, ideally, Id like the potentially troublesome optimizations to be
>> identified and gated by a prompt.
>>
>> Maybe we need a script thats run on the target box, that collects
>> the needed configuration factors; presumably including:
>> CPUFLAGS=`grep flags /proc/cpuinfo`
>> NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`
>>
>
> The problem is that we might not always have the target at hand when 
> building the user-space support (e.g. LiveCD, deployment distro 
> stuff). Therefore it could only be some optional helper, but not part 
> of the regular build process.
>
Ack. 
I was thinking in terms of a script run on target, which produces an .rc 
file,
which defines the factor=value pairs needed.
that file, if supplied to prepare-kernel as  --target-info=<foo>
would supply the customizations.
Yes, somewhat cumbersome..

Perhaps Ive just been lucky, 'cross-compiling' for 586 on 686.
Ill try hacking prepare-kernel and re-building.
>>
>> Somewhat related: prepare-kernel asks me for target architecture, I 
>> started by entering i586 explicitly,
>> but after a while, just took the i686 default.  Ive not noticed 
>> anything different/wrong,
>> but would appreciate confirmation/explanation.
>>
>
> Which information did you look at to determine that it was using the 
> 686 profile?
The script output told me.  In response to my post, Gilles sent me the 
snippet
from scripts/prepare-kernel where all x86) select i386.

Im not sure what youre asking, so I'll answer something (hopefully) close:
config/config.guess is providing the basis for the answer

if test x$linux_arch = x; then
   build_arch=`$xenomai_root/config/config.guess`
   default_linux_arch=`echo $build_arch|cut -f1 -d-`
fi

which 'returns' this:
        test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}" 
&& exit 0

ie
sh -vx config/config.guess
...
+ eval LIBC=gnu
LIBC=gnu
++ LIBC=gnu
+ test xgnu '!=' x
+ echo i686-pc-linux-gnu
i686-pc-linux-gnu


>
>> thanks
>> jimc
>>
>>
>> PS.  attached is an attempt to improve README.INSTALL along these and 
>> other lines.
will redo per your comments

Re: [Xenomai-help] Problems running testsuite

[Philippe Gerum]

Jim Cromie wrote:
> Philippe Gerum wrote:
> 
>> Jim Cromie wrote:
>>
>>> Gilles Chanteperdrix wrote:
>>>
>>>> Tobias Marschall wrote:
>>>>  > Hello,
>>>>  >  > On Thursday 13 April 2006 21:00, you wrote:
>>>>  > > I saw a similar error when using --enable-x86-sep and not 
>>>> having NPTL
>>>>  > > enabled in glibc.
>>>>  > > Try configuring without --enable-x86-sep (used in the 
>>>> README.INSTALL
>>>>  > > Pentium x86 example, the default is disabled).
>>>>  > that did the trick, thank you for the hint! I did check that the 
>>>> cpu supported  > the sep instruction, but I wasn't aware that NPTL 
>>>> is required in this case.
>>>>  >  > Mentioning this in README.INSTALL would be helpful. I wonder 
>>>> if that mistake  > could be caught by configure.
>>>> It could be caught by configure, at least if not cross-compiling, by
>>>> running getconf GNU_LIBPTHREAD_VERSION.
>>>>
>>>>   
>>>
>>>
>>> ie:
>>> [jimc@domain.hid xenomai]$ getconf GNU_LIBPTHREAD_VERSION
>>> NPTL 2.3.6
>>>
>>> doesnt /proc/cpuinfo, flags entry, indicate whether the cpu supports 
>>> SEP ?
>>>
>>
>> It should, yes.
>>
>>> flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca 
>>> cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
>>>
>>
>> Strange indeed, if that's a recent genuine Intel CPU.
>>
> 
> Well, Im not *stoned*, but it clearly looks like I am..
> heres the whole thing:
> 
> [jimc@domain.hid linux-2.6.16]$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 13
> model name      : Intel(R) Pentium(R) M processor 1.70GHz
> stepping        : 6
> cpu MHz         : 600.000
> cache size      : 2048 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov 
> pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
> bogomips        : 1198.01
> 
> 
> very strange.   Ive seen someone elses P-4 cpuinfo, flag is there, 
> spelled 'sep'
> 

Same here.

> 
>>>
>>> what x86 processors support --enable-x86-sep ?   Pentium-4 ?  Xeon ? 
>>> Athlon ?
>>> my Pentium-M apparently doesnt.
>>
>>
>> AFAIK, Intel supports sysenter/sysexit since the PII, and AMD 
>> introduced them with the K7. The genuine Pentium M does support them, 
>> no doubt.
>>
> Perhaps I need to email LKML.
> What would you expect if I built with --enable-sep (for my laptop) ?
> success / illegal-instruction exception / undefined-wierd behavior ?
>

Success or illegal instruction, I guess.

<snip>

>>> Maybe we need a script thats run on the target box, that collects
>>> the needed configuration factors; presumably including:
>>> CPUFLAGS=`grep flags /proc/cpuinfo`
>>> NPTL_AVAIL=`getconf GNU_LIBPTHREAD_VERSION`
>>>
>>
>> The problem is that we might not always have the target at hand when 
>> building the user-space support (e.g. LiveCD, deployment distro 
>> stuff). Therefore it could only be some optional helper, but not part 
>> of the regular build process.
>>
> Ack. I was thinking in terms of a script run on target, which produces 
> an .rc file,
> which defines the factor=value pairs needed.
> that file, if supplied to prepare-kernel as  --target-info=<foo>
> would supply the customizations.
> Yes, somewhat cumbersome..
>

Yep; Gilles's approach looking for potential configuration mismatch 
dynamically when running the target code seems easier to implement, and 
would provide a better coverage (e.g. building Xenomai for a 'generic' 
target).

> Perhaps Ive just been lucky, 'cross-compiling' for 586 on 686.
> Ill try hacking prepare-kernel and re-building.
> 
>>>
>>> Somewhat related: prepare-kernel asks me for target architecture, I 
>>> started by entering i586 explicitly,
>>> but after a while, just took the i686 default.  Ive not noticed 
>>> anything different/wrong,
>>> but would appreciate confirmation/explanation.
>>>
>>
>> Which information did you look at to determine that it was using the 
>> 686 profile?
> 
> The script output told me.  In response to my post, Gilles sent me the 
> snippet
> from scripts/prepare-kernel where all x86) select i386.
> 
> Im not sure what youre asking, so I'll answer something (hopefully) close:
> config/config.guess is providing the basis for the answer
> 
> if test x$linux_arch = x; then
>   build_arch=`$xenomai_root/config/config.guess`
>   default_linux_arch=`echo $build_arch|cut -f1 -d-`
> fi
> 
> which 'returns' this:
>        test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}" 
> && exit 0
> 
> ie
> sh -vx config/config.guess
> ...
> + eval LIBC=gnu
> LIBC=gnu
> ++ LIBC=gnu
> + test xgnu '!=' x
> + echo i686-pc-linux-gnu
> i686-pc-linux-gnu
> 

Ok, that is intended, but only if --arch is unspecified on the command 
line. Passing --arch=i586 should select i386 as the kernel architecture, 
which in turn causes the exact CPU profile to be obtained from Kconfig's 
current 'processor type and features' selection. The latter is what 
actually defines the arch-dependent compiler flags for the kernel (i.e. 
arch/i386/Makefile.cpu).

> 
>>
>>> thanks
>>> jimc
>>>
>>>
>>> PS.  attached is an attempt to improve README.INSTALL along these and 
>>> other lines.
> 
> will redo per your comments
> 


-- 

Philippe.

Re: [Xenomai-help] Problems running testsuite

[Gilles Chanteperdrix]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 321 bytes --]

Philippe Gerum wrote:
 > Looks good. Additionally, we might end up moving common portions of the 
 > various library constructors into a single file in order to reduce code 
 > duplication.

The attached patch tries to do that. The single file is named
include/nucleus/skin_init.h. 

-- 


					    Gilles Chanteperdrix.

[-- Attachment #2: skin-init.patch --]
[-- Type: text/plain, Size: 17158 bytes --]

Index: include/asm-generic/syscall.h
===================================================================
--- include/asm-generic/syscall.h	(revision 940)
+++ include/asm-generic/syscall.h	(working copy)
@@ -112,7 +112,7 @@
 #include <sys/types.h>
 #include <asm/xenomai/features.h>
 
-#endif /* __KERNEL__ */
+#endif /* !__KERNEL__ */
 
 typedef struct xncompletion {
 
Index: include/asm-i386/features.h
===================================================================
--- include/asm-i386/features.h	(revision 940)
+++ include/asm-i386/features.h	(working copy)
@@ -76,4 +76,35 @@
     }
 }
 
+#ifndef __KERNEL__
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+  size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+  if (n > 0)
+      {
+      char *buf = malloc(n);
+      int isnptl;
+      
+      confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
+      isnptl = strstr (buf, "NPTL");
+      free(buf);
+
+      if (isnptl)
+          return;
+      }
+
+  fprintf(stderr, "Xenomai: SEP instruction needs NPTL and NPTL was not detected"
+          "\nplease install NPTL or recompile Xenomai without enabling SEP.\n");
+  exit(1);
+#endif /* CONFIG_XENO_X86_SEP */
+}
+#define xeno_arch_features_check() xeno_x86_features_check()
+#endif /* __KERNEL__ */
+
 #endif /* !_XENO_ASM_I386_FEATURES_H */
Index: include/nucleus/Makefile.am
===================================================================
--- include/nucleus/Makefile.am	(revision 940)
+++ include/nucleus/Makefile.am	(working copy)
@@ -22,3 +22,5 @@
 	types.h \
 	version.h \
 	xenomai.h
+
+EXTRA_DIST = skin_init.h
Index: src/skins/rtai/init.c
===================================================================
--- src/skins/rtai/init.c	(revision 940)
+++ src/skins/rtai/init.c	(working copy)
@@ -19,6 +19,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <nucleus/skin_init.h>
 #include <rtai/syscall.h>
 
 int __rtai_muxid = -1;
@@ -26,45 +27,5 @@
 static __attribute__((constructor)) void __init_rtai_interface(void)
 
 {
-    xnfeatinfo_t finfo;
-    int muxid;
-
-    muxid = XENOMAI_SYSBIND(RTAI_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
-
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
-
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_rtai?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    __rtai_muxid = muxid;
-	    break;
-	}
+    __rtai_muxid = xeno_user_skin_init(RTAI_SKIN_MAGIC, "RTAI", "xeno_rtai");
 }
Index: src/skins/posix/init.c
===================================================================
--- src/skins/posix/init.c	(revision 940)
+++ src/skins/posix/init.c	(working copy)
@@ -23,6 +23,7 @@
 #include <limits.h>
 #include <unistd.h>
 #include <sys/types.h>
+#include <nucleus/skin_init.h>
 #include <posix/posix.h>
 #include <posix/syscall.h>
 #include <rtdm/syscall.h>
@@ -31,60 +32,14 @@
 int __rtdm_muxid  = -1;
 int __rtdm_fd_start = INT_MAX;
 
-void __handle_lock_alert (int sig)
-
-{
-    fprintf(stderr,"Xenomai: process memory not locked (missing mlockall?)\n");
-    fflush(stderr);
-    exit(4);
-}
-
 static __attribute__((constructor)) void __init_posix_interface(void)
 
 {
     struct sigaction sa;
-    xnfeatinfo_t finfo;
     int muxid;
+    
+    __pse51_muxid = xeno_user_skin_init(PSE51_SKIN_MAGIC, "POSIX", "xeno_posix");
 
-    muxid = XENOMAI_SYSBIND(PSE51_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
-
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
-
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: POSIX skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_posix?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    __pse51_muxid = muxid;
-	    break;
-	}
-
     muxid = XENOMAI_SYSBIND(RTDM_SKIN_MAGIC,
 			    XENOMAI_FEAT_DEP,
 			    XENOMAI_ABI_REV,
@@ -96,11 +51,4 @@
                                                          __rtdm_fdcount);
         }
 
-    /* Install a SIGXCPU handler to intercept alerts about unlocked
-       process memory. */
-
-    sa.sa_handler = &__handle_lock_alert;
-    sigemptyset(&sa.sa_mask);
-    sa.sa_flags = 0;
-    sigaction(SIGXCPU,&sa,NULL);
 }
Index: src/skins/vxworks/init.c
===================================================================
--- src/skins/vxworks/init.c	(revision 940)
+++ src/skins/vxworks/init.c	(working copy)
@@ -22,20 +22,13 @@
 #include <string.h>
 #include <stdlib.h>
 #include <pthread.h>
+#include <nucleus/skin_init.h>
 #include <vxworks/vxworks.h>
 
 pthread_key_t __vxworks_tskey;
 
 int __vxworks_muxid = -1;
 
-void __handle_lock_alert (int sig)
-
-{
-    fprintf(stderr,"Xenomai: process memory not locked (missing mlockall?)\n");
-    fflush(stderr);
-    exit(4);
-}
-
 static void __flush_tsd (void *tsd)
 
 {
@@ -46,62 +39,15 @@
 static __attribute__((constructor)) void __init_xeno_interface(void)
 
 {
-    struct sigaction sa;
-    xnfeatinfo_t finfo;
-    int muxid;
-
-    muxid = XENOMAI_SYSBIND(VXWORKS_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
-
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
-
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: VxWorks skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_vxworks?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    /* Allocate a TSD key for indexing self task pointers. */
-
-	    if (pthread_key_create(&__vxworks_tskey,&__flush_tsd) != 0)
-		{
-		fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
-		exit(1);
-		}
-
-	    __vxworks_muxid = muxid;
-	    break;
-	}
-
-    /* Install a SIGXCPU handler to intercept alerts about unlocked
-       process memory. */
-
-    sa.sa_handler = &__handle_lock_alert;
-    sigemptyset(&sa.sa_mask);
-    sa.sa_flags = 0;
-    sigaction(SIGXCPU,&sa,NULL);
+    __vxworks_muxid = xeno_user_skin_init(VXWORKS_SKIN_MAGIC,
+                                          "VxWorks",
+                                          "xeno_vxworks");
+    
+    /* Allocate a TSD key for indexing self task pointers. */
+    
+    if (pthread_key_create(&__vxworks_tskey,&__flush_tsd) != 0)
+        {
+        fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
+        exit(1);
+        }
 }
Index: src/skins/vrtx/init.c
===================================================================
--- src/skins/vrtx/init.c	(revision 940)
+++ src/skins/vrtx/init.c	(working copy)
@@ -22,20 +22,13 @@
 #include <signal.h>
 #include <stdlib.h>
 #include <pthread.h>
+#include <nucleus/skin_init.h>
 #include <vrtx/vrtx.h>
 
 pthread_key_t __vrtx_tskey;
 
 int __vrtx_muxid = -1;
 
-void __handle_lock_alert (int sig)
-
-{
-    fprintf(stderr,"Xenomai: process memory not locked (missing mlockall?)\n");
-    fflush(stderr);
-    exit(4);
-}
-
 static void __flush_tsd (void *tsd)
 
 {
@@ -46,69 +39,25 @@
 static __attribute__((constructor)) void __init_xeno_interface(void)
 
 {
-    struct sigaction sa;
-    xnfeatinfo_t finfo;
-    int muxid;
     TCB *tcb;
 
-    muxid = XENOMAI_SYSBIND(VRTX_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
+    __vrtx_muxid = xeno_user_skin_init(VRTX_SKIN_MAGIC, "VRTX", "xeno_vrtx");
+    
+    /* Allocate a TSD key for indexing self task pointers. */
 
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
+    if (pthread_key_create(&__vrtx_tskey,&__flush_tsd) != 0)
+        {
+        fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
+        exit(1);
+        }
 
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: VRTX skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_vrtx?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    /* Allocate a TSD key for indexing self task pointers. */
-
-	    if (pthread_key_create(&__vrtx_tskey,&__flush_tsd) != 0)
-		{
-		fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
-		exit(1);
-		}
-
-	    tcb = (TCB *)malloc(sizeof(*tcb));
-
-	    if (!tcb)
-		{
-		fprintf(stderr,"Xenomai: failed to allocate local TCB?!\n");
-		exit(1);
-		}
-
-	    pthread_setspecific(__vrtx_tskey,tcb);
-	    __vrtx_muxid = muxid;
-	    break;
-	}
-
-    sa.sa_handler = &__handle_lock_alert;
-    sigemptyset(&sa.sa_mask);
-    sa.sa_flags = 0;
-    sigaction(SIGXCPU,&sa,NULL);
+    tcb = (TCB *)malloc(sizeof(*tcb));
+    
+    if (!tcb)
+        {
+        fprintf(stderr,"Xenomai: failed to allocate local TCB?!\n");
+        exit(1);
+        }
+    
+    pthread_setspecific(__vrtx_tskey,tcb);
 }
Index: src/skins/native/init.c
===================================================================
--- src/skins/native/init.c	(revision 940)
+++ src/skins/native/init.c	(working copy)
@@ -22,6 +22,7 @@
 #include <signal.h>
 #include <stdlib.h>
 #include <pthread.h>
+#include <nucleus/skin_init.h>
 #include <native/syscall.h>
 #include <native/task.h>
 
@@ -29,14 +30,6 @@
 
 int __native_muxid = -1;
 
-void __handle_lock_alert (int sig)
-
-{
-    fprintf(stderr,"Xenomai: process memory not locked (missing mlockall?)\n");
-    fflush(stderr);
-    exit(4);
-}
-
 static void __flush_tsd (void *tsd)
 
 {
@@ -47,62 +40,13 @@
 static __attribute__((constructor)) void __init_xeno_interface(void)
 
 {
-    struct sigaction sa;
-    xnfeatinfo_t finfo;
-    int muxid;
+    __native_muxid = xeno_user_skin_init(XENO_SKIN_MAGIC,"native","xeno_native");
+    
+    /* Allocate a TSD key for indexing self task pointers. */
 
-    muxid = XENOMAI_SYSBIND(XENO_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
-
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
-
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_native?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    /* Allocate a TSD key for indexing self task pointers. */
-
-	    if (pthread_key_create(&__native_tskey,&__flush_tsd) != 0)
-		{
-		fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
-		exit(1);
-		}
-
-	    __native_muxid = muxid;
-	    break;
-	}
-
-    /* Install a SIGXCPU handler to intercept alerts about unlocked
-       process memory. */
-
-    sa.sa_handler = &__handle_lock_alert;
-    sigemptyset(&sa.sa_mask);
-    sa.sa_flags = 0;
-    sigaction(SIGXCPU,&sa,NULL);
+    if (pthread_key_create(&__native_tskey,&__flush_tsd) != 0)
+        {
+        fprintf(stderr,"Xenomai: failed to allocate new TSD key?!\n");
+        exit(1);
+        }    
 }
Index: src/skins/rtdm/init.c
===================================================================
--- src/skins/rtdm/init.c	(revision 940)
+++ src/skins/rtdm/init.c	(working copy)
@@ -30,6 +30,10 @@
     xnfeatinfo_t finfo;
     int muxid;
 
+#ifdef xeno_arch_features_check
+    xeno_arch_features_check();
+#endif /* xeno_arch_features_check */
+
     muxid = XENOMAI_SYSBIND(RTDM_SKIN_MAGIC,
 			    XENOMAI_FEAT_DEP,
 			    XENOMAI_ABI_REV,
Index: src/skins/uvm/init.c
===================================================================
--- src/skins/uvm/init.c	(revision 940)
+++ src/skins/uvm/init.c	(working copy)
@@ -20,6 +20,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
+#include <nucleus/skin_init.h>
 #include <asm-uvm/syscall.h>
 
 int __uvm_muxid = -1;
@@ -32,43 +33,7 @@
     xnfeatinfo_t finfo;
     int muxid;
 
-    muxid = XENOMAI_SYSBIND(UVM_SKIN_MAGIC,
-			    XENOMAI_FEAT_DEP,
-			    XENOMAI_ABI_REV,
-			    &finfo);
-    switch (muxid)
-	{
-	case -EINVAL:
+    __uvm_muxid = xeno_user_skin_init(UVM_SKIN_MAGIC, "UVM", "xeno_uvm");
 
-	    fprintf(stderr,"Xenomai: incompatible feature set\n");
-	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
-		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-	    exit(1);
-
-	case -ENOEXEC:
-
-	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
-	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
-		    XENOMAI_ABI_REV,finfo.abirev);
-	    exit(1);
-
-	case -ENOSYS:
-	case -ESRCH:
-
-	    fprintf(stderr,"Xenomai: UVM skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n");
-	    fprintf(stderr,"(modprobe xeno_uvm?)\n");
-	    exit(1);
-
-	default:
-
-	    if (muxid < 0)
-		{
-		fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
-		exit(1);
-		}
-
-	    XENOMAI_SYSCALL2(__xn_sys_info,muxid,&__uvm_info);
-	    __uvm_muxid = muxid;
-	    break;
-	}
+    XENOMAI_SYSCALL2(__xn_sys_info,muxid,&__uvm_info);
 }
--- /dev/null	2006-04-16 14:39:13.372574250 +0200
+++ include/nucleus/skin_init.h	2006-04-17 19:05:58.000000000 +0200
@@ -0,0 +1,73 @@
+#ifndef _XENO_NUCLEUS_SKIN_INIT_H
+#define _XENO_NUCLEUS_SKIN_INIT_H
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <errno.h>
+#include <asm/xenomai/syscall.h>
+
+static void __handle_lock_alert (int sig)
+
+{
+    fprintf(stderr,"Xenomai: process memory not locked (missing mlockall?)\n");
+    fflush(stderr);
+    exit(4);
+}
+
+static int
+xeno_user_skin_init(unsigned skin_magic, const char *skin, const char *module)
+{
+    xnfeatinfo_t finfo;
+    int muxid;
+
+#ifdef xeno_arch_features_check
+    xeno_arch_features_check();
+#endif /* xeno_arch_features_check */
+    
+    muxid = XENOMAI_SYSBIND(skin_magic,
+			    XENOMAI_FEAT_DEP,
+			    XENOMAI_ABI_REV,
+			    &finfo);
+    switch (muxid)
+	{
+	case -EINVAL:
+
+	    fprintf(stderr,"Xenomai: incompatible feature set\n");
+	    fprintf(stderr,"(required=\"%s\", present=\"%s\", missing=\"%s\").\n",
+		    finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
+	    exit(1);
+
+	case -ENOEXEC:
+
+	    fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
+	    fprintf(stderr,"(needed=%lu, current=%lu).\n",
+		    XENOMAI_ABI_REV,finfo.abirev);
+	    exit(1);
+
+	case -ENOSYS:
+	case -ESRCH:
+
+	    fprintf(stderr,"Xenomai: %s skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n"
+                    "(modprobe %s?)\n", skin, module);
+	    exit(1);
+        }
+    
+    if (muxid < 0)
+        {
+        fprintf(stderr,"Xenomai: binding failed: %s.\n",strerror(-muxid));
+        exit(1);
+        }
+
+    /* Install a SIGXCPU handler to intercept alerts about unlocked
+       process memory. */
+
+    sa.sa_handler = &__handle_lock_alert;
+    sigemptyset(&sa.sa_mask);
+    sa.sa_flags = 0;
+    sigaction(SIGXCPU,&sa,NULL);
+
+    return muxid;
+}
+
+#endif /* _XENO_NUCLEUS_SKIN_INIT_H */