[Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Hi,

I use Xenomai (and RTAI  before) to introduce real time Linux in a course I
ran at the university of Algarve :

http://tutoria.ualg.pt/2014/course/view.php?id=2067

This year we moved to Xenomai version 3.x series.
We start using Mercury because its easier to teach students install in any
pc (at least to work as a simulator over a not full real time vanilla
kernel)

Now I am trying to install Xenomai 3.x-rc3 with dual-core cobalt kernel.
I already installed Mercury single kernel, over a vanilla kernel and a
PREEMPT_RT patched kernel and run successfully the demo apps, like
"latency", and some simple apps,kernel and user space, that i developed for
previous Xenomai and RTAI versions (following the migration documentation)

However with Mercury flavour I couldn't make the registry to work, to share
some named Xenomai syncronization objects,like mutexes across different
processes,although xenomai be configured with:

./configure --with-core=mercury --enable-registry

When trying to run apps it gives me an error saying that the registry
daemon is not working:

   3"004.187| WARNING: [main] cannot connect to registry daemon
   3"004.187| BUG: [main] initialization failed, EAGAIN

Also could not find registry at /var/run/xenomai/...
This folder is not even present.

But Apps were compiled with xenomai support, using xeno-config to get the
parameters. The makefile that i use with my apps:

target =  simple
skin   :=  native       #or in v3.x SKIN   :=  alchemy

CFLAGS := $(shell xeno-config --skin=$(skin) --cflags)
LDFLAGS := $(shell xeno-config --skin=$(skin) --ldflags)

$(target): $(target).c
$(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)



Disabling registry support passing the switch:

--no-registry

Apps run fine, however I have no registry support to share objects between
different processes. I can not bind to a Xenomai object created by one
process from other process.

So I tried to install cobalt to see if I could work with the registry (and
also to try it :))

I patch a kernel 2.14.28 with patch ipipe-core-3.14.28-x86-7.patch

I think this is the right patch for that kernel.
It give me no errors when patching, but I am not sure because I tried
before to patch kernel 2.16.2 with ipipe-core-3.16-x86-2.patch
it gave me also no errors when patching, but then I suspected that maybe it
is the wrong kernel source and that this patch is to apply on a 3.16
kernel(3.16 not 3.16.2). Is this right?

So I patch another kernel, from kernel.org archives, with another patch:

kernel 2.14.28 with ipipe-core-3.14.28-x86-7.patch

hoping thats the right patch to this kernel.

When I run make menuconfig the Xenomai/cobalt section was present so i
think the patch was applied correcty.

I configure it according to xenomai install notes:

http://xenomai.org/installing-xenomai-3-x/#Configuring_and_compiling_the_Cobalt_kernel

namely:

CONFIG_X86_MINIMUM_CPU_FAMILY=5 #Pentium 4

# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_APM is not set
# CONFIG_ACPI is not set
# CONFIG_ACPI_PROCESSOR  is not set

# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_INTEL_IDLE is not set
# CONFIG_INPUT_PCSPKR is not set

# CONFIG_KGDB  is not set

And append to version name the version as ipipe:

CONFIG_LOCALVERSION="-ipipe"

I created 2 debian packages to install. One with kernel image and the other
with the headers:

make-kpkg --initrd kernel_image kernel_headers

So I install it with:

dpkg -i linux-headers-3.14.28-ipipe_3.14.28-ipipe-10.00.Custom_i386.deb
dpkg -i linux-image-3.14.28-ipipe_3.14.28-ipipe-10.00.Custom_i386.deb

Then I recompile Xenomai to cobalt:

> make clean
> ./configure --with-core=cobalt --enable-registry
> make install

I configure xeno PATHs and libs:

a) add to the end of /etc/ld.so.conf

/usr/xenomai/lib

and execute: ldconfig

b) add to the end of /etc/profile :

export PATH=$PATH:/usr/xenomai/bin
export MANPATH=$MANPATH:/usr/xenomai/share/man/

then I reboot it with new patched kernel 3.14.28 and
then when trying to run:

/usr/xenomai/bin/latency

it gives the error:

Xenomai/cobalt: low_init(): binding failed: Function not implemented error

The same with Apps of my own.

I tried to find for xenomai in boot log with:

dmesg | grep -i xenomai

it returns me:

[    0.868031] [Xenomai] scheduling class idle registered.
[    0.868031] [Xenomai] scheduling class rt registered.
[    0.868031] [Xenomai] init failed, code -19

Also I noticed in the boot messages some issue with xenomai and udev:

udevd[337]: specified group 'xenomai' unknown

I already tried to find help in the mailing list archives but i could not
find a solution (maybe i did not look at the right messages :( )

It is possible that I am applying the wrong patch for the wrong kernel?

I thank any suggestion you may have.

PS: I am running on Debian 7.8 on a virtual machine (VMWare player 7) on a
AMD Athlon processor and also on a dual core
Intel core 2 duo P8600.
I did not try to install on a physical pc yet because the idea is to get a
VMware image Xenomai ready for student to run rigth at the beginning of the
course.
However previous versions of xenomai were sucessfuly ran over VMware, so I
was not expecting issues here (but maybe I should try on a physicl pc)





great work with Xenomai :)


Helder



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 09:49 AM, Helder Daniel wrote:
> ./configure --with-core=mercury --enable-registry
> 
> When trying to run apps it gives me an error saying that the registry
> daemon is not working:
> 
>    3"004.187| WARNING: [main] cannot connect to registry daemon
>    3"004.187| BUG: [main] initialization failed, EAGAIN
> 
> Also could not find registry at /var/run/xenomai/...
> This folder is not even present.
>

If the registry could not be mounted, then you can't see it, that is
expected.

1. Do you have /var/run on your system?

2. Does passing --registry-root=/tmp to the application fix the issue?

3. Did you enable CONFIG_FUSE_FS in your kernel configuration? You need
this for supporting the new registry.

> But Apps were compiled with xenomai support, using xeno-config to get the
> parameters. The makefile that i use with my apps:
> 
> target =  simple
> skin   :=  native       #or in v3.x SKIN   :=  alchemy

For compat purpose with legacy Makefiles, you can use "native" with
xeno-config. It will implicitly translate this to "alchemy".

> I patch a kernel 2.14.28 with patch ipipe-core-3.14.28-x86-7.patch
> 
> I think this is the right patch for that kernel.
> It give me no errors when patching, but I am not sure because I tried
> before to patch kernel 2.16.2 with ipipe-core-3.16-x86-2.patch
> it gave me also no errors when patching, but then I suspected that maybe it
> is the wrong kernel source and that this patch is to apply on a 3.16
> kernel(3.16 not 3.16.2). Is this right?
> 

Sorry, I can't figure out whether you are actually reporting an issue,
or just thinking out loud. In any case, ipipe-core-3.16-x86-2 does not
mean that the relevant patch was based on 3.16.2. Instead, this means
that it's the second revision of that patch for 3.16[.0].
Note the architecture label separating the kernel release from the
revision number.

> So I patch another kernel, from kernel.org archives, with another patch:
> 
> kernel 2.14.28 with ipipe-core-3.14.28-x86-7.patch
> 
> hoping thats the right patch to this kernel.
> 
> When I run make menuconfig the Xenomai/cobalt section was present so i
> think the patch was applied correcty.
> 

There is no correlation here. You might have portions of the pipeline
patch failing to apply to your kernel, with the Xenomai Kconfig bits
applying properly. You would end up with a half-baked kernel in such an
event.

> I configure it according to xenomai install notes:
> 
> http://xenomai.org/installing-xenomai-3-x/#Configuring_and_compiling_the_Cobalt_kernel
> 
> namely:

> # CONFIG_CC_STACKPROTECTOR is not set
> # CONFIG_INPUT_PCSPKR is not set
> 

Disabling these ones is not required with Xenomai 3 over x86_32/64,
although I haven't enabled PCSPKR for ages. At any rate, the obsolete
TSC emulation code that required to disable it is gone.

> /usr/xenomai/bin/latency
> 
> it gives the error:
> 
> Xenomai/cobalt: low_init(): binding failed: Function not implemented error
> 

This is expected since the Cobalt core could not initialize on your system.

> The same with Apps of my own.
> 

All apps have to run low_init() successfully for attaching to the
real-time system, so this is expected too.

> I tried to find for xenomai in boot log with:
> 
> dmesg | grep -i xenomai
> 
> it returns me:
> 
> [    0.868031] [Xenomai] scheduling class idle registered.
> [    0.868031] [Xenomai] scheduling class rt registered.
> [    0.868031] [Xenomai] init failed, code -19
> 

The machine setup likely failed during the Xenomai inits. Typically,
failing to grab the hardware timer would beget this. I would try on real
hardware to confirm that the issue may be caused by the virtualized
platform.

> Also I noticed in the boot messages some issue with xenomai and udev:
> 
> udevd[337]: specified group 'xenomai' unknown

You have to define such group if you plan to apply this udev rule to
RTDM devices.

> PS: I am running on Debian 7.8 on a virtual machine (VMWare player 7) on a
> AMD Athlon processor and also on a dual core
> Intel core 2 duo P8600.
> I did not try to install on a physical pc yet because the idea is to get a
> VMware image Xenomai ready for student to run rigth at the beginning of the
> course.
> However previous versions of xenomai were sucessfuly ran over VMware, so I
> was not expecting issues here (but maybe I should try on a physicl pc)
> 

Xenomai 3 relies on the same pipeline series than Xenomai 2.x running on
recent kernels, there is nothing in the Cobalt core that will prevent
from running over a virtual environment. I'm not using VMware so I won't
comment further. KVM is fine and the preferred VM system among Xenomai
maintainers, some also reported success with virtualbox.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 02:03 PM, Helder Daniel wrote:
> Hi Philippe,
> 
> Thanks for your very quick response.
> I am installing cobalt in a physical pc for testing cobalt.
> 
> Meanwhile I tried what you suggested to check the registry in Mercury:
> 
>> If the registry could not be mounted, then you can't see it, that is
>> expected.
>> 1. Do you have /var/run on your system?
>>
> Yes I have (but no xenomai entry):
> 
> ls /var/run
> 
> acpid.pid               exim4               NetworkManager.pid
>  sm-notify.pid
> acpid.socket            gdm3                pm-utils            sshd
> atd.pid                 gdm3.pid            rpcbind             sshd.pid
> avahi-daemon            initctl             rpcbind.lock        udev
> console                 initramfs           rpcbind.pid         udisks
> ConsoleKit              lock                rpcbind.sock        utmp
> console-kit-daemon.pid  motd.dynamic        rpc.statd.pid       vmblock-fuse
> crond.pid               mount               rsyslogd.pid        vmtoolsd.pid
> crond.reboot            mpt-statusd.pid     sdp
> dbus                    mpt-statusd.status  sendsigs.omit.d
> dhclient.eth0.pid       network             shm
> 
>> 2. Does passing --registry-root=/tmp to the application fix the issue?
> 
> No. Gives the same error:
> 
> ./writeport --registry-root=/tmp
>    3"004.187| WARNING: [main] cannot connect to registry daemon
>    3"004.187| BUG: [main] initialization failed, EAGAIN

Does your PATH variable include $prefix/sbin?
(typically /usr/xenomai/sbin unless you set a different installation
prefix when configuring).

Bottom line is that the sysregd executable must be found when scanning
the PATH variable.

PS: please keep the list posted. This discussion may be useful to other
users.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 02:59 PM, Philippe Gerum wrote:
> On 03/03/2015 02:03 PM, Helder Daniel wrote:
>> Hi Philippe,
>>
>> Thanks for your very quick response.
>> I am installing cobalt in a physical pc for testing cobalt.
>>
>> Meanwhile I tried what you suggested to check the registry in Mercury:
>>
>>> If the registry could not be mounted, then you can't see it, that is
>>> expected.
>>> 1. Do you have /var/run on your system?
>>>
>> Yes I have (but no xenomai entry):
>>
>> ls /var/run
>>
>> acpid.pid               exim4               NetworkManager.pid
>>  sm-notify.pid
>> acpid.socket            gdm3                pm-utils            sshd
>> atd.pid                 gdm3.pid            rpcbind             sshd.pid
>> avahi-daemon            initctl             rpcbind.lock        udev
>> console                 initramfs           rpcbind.pid         udisks
>> ConsoleKit              lock                rpcbind.sock        utmp
>> console-kit-daemon.pid  motd.dynamic        rpc.statd.pid       vmblock-fuse
>> crond.pid               mount               rsyslogd.pid        vmtoolsd.pid
>> crond.reboot            mpt-statusd.pid     sdp
>> dbus                    mpt-statusd.status  sendsigs.omit.d
>> dhclient.eth0.pid       network             shm
>>
>>> 2. Does passing --registry-root=/tmp to the application fix the issue?
>>
>> No. Gives the same error:
>>
>> ./writeport --registry-root=/tmp
>>    3"004.187| WARNING: [main] cannot connect to registry daemon
>>    3"004.187| BUG: [main] initialization failed, EAGAIN
> 
> Does your PATH variable include $prefix/sbin?
> (typically /usr/xenomai/sbin unless you set a different installation
> prefix when configuring).
> 
> Bottom line is that the sysregd executable must be found when scanning
> the PATH variable.
> 

No actually, you don't need that if sysregd still appears in
$prefix/sbin as built.

Please send the output of "strace -f" on the latency executable.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

>
>
> No actually, you don't need that if sysregd still appears in
> $prefix/sbin as built.
>
> Please send the output of "strace -f" on the latency executable.
>
> Ok. I tried putting sbin in the search path and gave the same error.

I am running these test now on an installation of Mercury (already on an
AMD Sempron physical system).

/usr/xenomai/bin/latency runs fine on this installation (the issue with
latency not running is with Cobalt installation)

I think I have 2 different problems:

1) can not use Xenomai registry in Mercury and Cobalt.

2) actually I can not run anything at all in Cobalt installation (possibly
a bad patch)

To test registry in Mercury I tried to run a simple app, that gives the
registry daemon error:

./hello
   3"002.332| WARNING: [main] cannot connect to registry daemon
   3"002.425| BUG: [main] initialization failed, EAGAIN

The code is just that below. It makes no calls to Xenomai libs:

#include <stdio.h>
main() {
    puts ("Hello");
    return 0;
}

But it was compiled with Xenomai support. Makefile:

target =  hello

CFLAGS  := $(shell xeno-config --skin=$(skin) --cflags)
LDFLAGS := $(shell xeno-config --skin=$(skin) --ldflags)

$(target): $(target).c
    $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)

The strace -f of this simple app is below.
(After this trace is also the strace -f of latency, which runs fine in
Mercury, but I guess you might want the starce of the not running latency
executable in Cobalt?)

$> strace -f ./hello
execve("./hello", ["./hello"], [/* 18 vars */]) = 0
brk(0)                                  = 0x97bf000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7705000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=74726, ...}) = 0
mmap2(NULL, 74726, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76f2000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/usr/xenomai/lib/libalchemy.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200=\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=66781, ...}) = 0
mmap2(NULL, 77164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76df000
mmap2(0xb76ec000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc) = 0xb76ec000
mmap2(0xb76ed000, 19820, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76ed000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/usr/xenomai/lib/libcopperplate.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pW\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=111928, ...}) = 0
mmap2(NULL, 98184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76c7000
mmap2(0xb76dd000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0xb76dd000
mmap2(0xb76de000, 3976, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76de000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117010, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb76c6000
mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76ad000
mmap2(0xb76c2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb76c2000
mmap2(0xb76c4000, 4608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76c4000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76a4000
mmap2(0xb76ab000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb76ab000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/libfuse.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`_\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=211296, ...}) = 0
mmap2(NULL, 209924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7670000
mmap2(0xb769a000, 40960, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a) = 0xb769a000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1446056, ...}) = 0
mmap2(NULL, 1456504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb750c000
mmap2(0xb766a000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e) = 0xb766a000
mmap2(0xb766d000, 10616, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb766d000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libdl.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9844, ...}) = 0
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7508000
mmap2(0xb750a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb750a000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7507000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7506000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75066d0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
mprotect(0xb750a000, 4096, PROT_READ)   = 0
mprotect(0xb766a000, 8192, PROT_READ)   = 0
mprotect(0xb769a000, 36864, PROT_READ)  = 0
mprotect(0xb76ab000, 4096, PROT_READ)   = 0
mprotect(0xb76c2000, 4096, PROT_READ)   = 0
mprotect(0xb7724000, 4096, PROT_READ)   = 0
munmap(0xb76f2000, 74726)               = 0
set_tid_address(0xb7506738)             = 4037
set_robust_list(0xb7506740, 0xc)        = 0
futex(0xbff4bb00, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
bff4bb10) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb76b16e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb76b1b70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="LinuxSTR", ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {1865, 334707182}) = 0
futex(0xb76ddaa8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
gettid()                                = 4037
brk(0)                                  = 0x97bf000
brk(0x97e0000)                          = 0x97e0000
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7702000
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7405000
socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
ECONNREFUSED (Connection refused)
close(3)                                = 0
rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
vfork(Process 4038 attached
)                                 = 4038
[pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
[pid  4037] nanosleep({1, 0},  <unfinished ...>
[pid  4038] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
"/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
directory)
[pid  4038] exit_group(1)               = ?
Process 4038 detached
<... nanosleep resumed> 0xbff4b8c4)     = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
ECONNREFUSED (Connection refused)
close(3)                                = 0
rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
vfork(Process 4039 attached
)                                 = 4039
[pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
[pid  4037] nanosleep({1, 0},  <unfinished ...>
[pid  4039] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
"/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
directory)
[pid  4039] exit_group(1)               = ?
Process 4039 detached
<... nanosleep resumed> 0xbff4b8c4)     = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
ECONNREFUSED (Connection refused)
close(3)                                = 0
rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
vfork(Process 4040 attached
)                                 = 4040
[pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
[pid  4037] nanosleep({1, 0},  <unfinished ...>
[pid  4040] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
"/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
directory)
[pid  4040] exit_group(1)               = ?
Process 4040 detached
<... nanosleep resumed> 0xbff4b8c4)     = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {1868, 344105213}) = 0
rt_sigprocmask(SIG_BLOCK, [RT_10], [], 8) = 0
write(2, "   3\"009.398| ", 14   3"009.398| )         = 14
write(2, "WARNING: ", 9WARNING: )                = 9
write(2, "[main] ", 7[main] )                  = 7
write(2, "cannot connect to registry daemo"..., 33cannot connect to
registry daemon) = 33
write(2, "\n", 1
)                       = 1
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {1868, 344487920}) = 0
rt_sigprocmask(SIG_BLOCK, [RT_10], [], 8) = 0
write(2, "   3\"009.780| ", 14   3"009.780| )         = 14
write(2, "BUG: ", 5BUG: )                    = 5
write(2, "[main] ", 7[main] )                  = 7
write(2, "initialization failed, EAGAIN", 29initialization failed, EAGAIN)
= 29
write(2, "\n", 1
)                       = 1
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(1)                           = ?



=================
The strace -f of latency
=================

This is the output to STDIN (so its running on Mercury but not in Cobalt)
Below is the strace (STDERR output)

strace -f latency 2> t
== 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, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|     33.361|     35.795|   1835.884|      47|     0|     33.361|
1835.884
RTD|     33.354|     38.507|   6591.060|     219|     0|     33.354|
6591.060
(...)

STRACE:

$> head stderr.output -n 150
execve("/usr/xenomai/bin/latency", ["latency"], [/* 18 vars */]) = 0
brk(0)                                  = 0x902a000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7720000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=74726, ...}) = 0
mmap2(NULL, 74726, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb770d000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/libfuse.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`_\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=211296, ...}) = 0
mmap2(NULL, 209924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76d9000
mmap2(0xb7703000, 40960, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a) = 0xb7703000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117010, ...}) = 0
mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76c0000
mmap2(0xb76d5000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb76d5000
mmap2(0xb76d7000, 4608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76d7000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb76bf000
mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76b6000
mmap2(0xb76bd000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb76bd000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libm.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2604\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=148996, ...}) = 0
mmap2(NULL, 151680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7690000
mmap2(0xb76b4000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) = 0xb76b4000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1446056, ...}) = 0
mmap2(NULL, 1456504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb752c000
mmap2(0xb768a000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e) = 0xb768a000
mmap2(0xb768d000, 10616, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb768d000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libdl.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9844, ...}) = 0
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7528000
mmap2(0xb752a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb752a000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7527000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7526000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75266c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
mprotect(0xb752a000, 4096, PROT_READ)   = 0
mprotect(0xb768a000, 8192, PROT_READ)   = 0
mprotect(0xb76b4000, 4096, PROT_READ)   = 0
mprotect(0xb76bd000, 4096, PROT_READ)   = 0
mprotect(0xb76d5000, 4096, PROT_READ)   = 0
mprotect(0xb7703000, 36864, PROT_READ)  = 0
mprotect(0xb773f000, 4096, PROT_READ)   = 0
munmap(0xb770d000, 74726)               = 0
set_tid_address(0xb7526728)             = 4215
set_robust_list(0xb7526730, 0xc)        = 0
futex(0xbffec710, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
bffec720) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb76c46e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb76c4b70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="LinuxSTR", ...}) = 0
time(NULL)                              = 1425394452
brk(0)                                  = 0x902a000
brk(0x904b000)                          = 0x904b000
rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM TERM], NULL, 8) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb771f000
write(1, "== Sampling period: 100 us\n", 27) = 27
write(1, "== Test mode: periodic user-mode"..., 69) = 69
mlockall(MCL_CURRENT|MCL_FUTURE)        = 0
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6d25000
mprotect(0xb6d25000, 4096, PROT_NONE)   = 0
clone(Process 4216 attached
child_stack=0xb7525494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb7525bd8, {entry_number:6, base_addr:0xb7525b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}, child_tidptr=0xb7525bd8) = 4216
[pid  4215] sched_get_priority_min(SCHED_FIFO) = 1
[pid  4215] sched_get_priority_max(SCHED_FIFO) = 99
[pid  4215] mmap2(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0 <unfinished ...>
[pid  4216] set_robust_list(0xb7525be0, 0xc) = 0
[pid  4216] prctl(PR_SET_NAME, 0xb7525328, 0x804d2e4, 0, 0xb76c1614) = 0
[pid  4216] statfs("/dev/shm",  <unfinished ...>
[pid  4215] <... mmap2 resumed> )       = 0xb6524000
[pid  4216] <... statfs resumed> {f_type=0x1021994, f_bsize=4096,
f_blocks=494345, f_bfree=494246, f_bavail=494246, f_files=221793,
f_ffree=221780, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
[pid  4216] futex(0xb76d81a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid  4216] unlink("/dev/shm/sem.dispsem-4215") = -1 ENOENT (No such file
or directory)
[pid  4216] gettimeofday({1425394452, 324990}, NULL) = 0
[pid  4216] lstat64("/dev/shm/sem.i6kEQQ", 0xb7525180) = -1 ENOENT (No such
file or directory)
[pid  4216] open("/dev/shm/sem.i6kEQQ", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
[pid  4216] write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16
[pid  4216] mmap2(NULL, 16, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) =
0xb771e000
[pid  4216] link("/dev/shm/sem.i6kEQQ", "/dev/shm/sem.dispsem-4215") = 0
[pid  4216] fstat64(3, {st_mode=S_IFREG|0644, st_size=16, ...}) = 0
[pid  4216] unlink("/dev/shm/sem.i6kEQQ") = 0
[pid  4216] close(3)                    = 0
[pid  4216] time(NULL)                  = 1425394452
[pid  4216] write(1, "warming up...\n", 14) = 14
[pid  4216] futex(0xb771e000, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  4215] mprotect(0xb6524000, 4096, PROT_NONE) = 0
[pid  4215] sched_get_priority_min(SCHED_FIFO) = 1
[pid  4215] sched_get_priority_max(SCHED_FIFO) = 99
[pid  4215] clone(Process 4217 attached
child_stack=0xb6d24494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb6d24bd8, {entry_number:6, base_addr:0xb6d24b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}, child_tidptr=0xb6d24bd8) = 4217
[pid  4215] sched_setscheduler(4217, SCHED_FIFO, { 99 } <unfinished ...>
[pid  4217] set_robust_list(0xb6d24be0, 0xc) = 0
[pid  4217] futex(0xb6d24d84, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
[pid  4215] <... sched_setscheduler resumed> ) = 0
[pid  4215] futex(0xb6d24d84, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid  4217] <... futex resumed> )       = 0
[pid  4217] futex(0xb6d24d84, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  4217] prctl(PR_SET_NAME, 0xb6d24370, 0, 0, 0xb768bff4) = 0
[pid  4217] timerfd_create(CLOCK_MONOTONIC, 0) = 3
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 404514401}) = 0
[pid  4217] timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 100000},
it_value={2209, 405514401}}, NULL) = 0
[pid  4217] read(3,  <unfinished ...>
[pid  4215] <... futex resumed> )       = 1
[pid  4215] rt_sigtimedwait([HUP INT ALRM TERM], NULL, NULL, 8 <unfinished
...>
[pid  4217] <... read resumed> "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405588957}) = 0
[pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405652882}) = 0
[pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405749665}) = 0
[pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405849010}) = 0
[pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405948555}) = 0
[pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
(...)
It continues ....

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

PS:

When I said above "(possibly a bad patch)" I meant a bad patching
application.
I must be doing something wrong.
I am trying again to apply the ipipe patch and configure kernel from
scratch now on a physical machine.

thank for all your help,

Helder

On 3 March 2015 at 14:58, Helder Daniel <hdaniel@ualg.pt> wrote:

>
>> No actually, you don't need that if sysregd still appears in
>> $prefix/sbin as built.
>>
>> Please send the output of "strace -f" on the latency executable.
>>
>> Ok. I tried putting sbin in the search path and gave the same error.
>
> I am running these test now on an installation of Mercury (already on an
> AMD Sempron physical system).
>
> /usr/xenomai/bin/latency runs fine on this installation (the issue with
> latency not running is with Cobalt installation)
>
> I think I have 2 different problems:
>
> 1) can not use Xenomai registry in Mercury and Cobalt.
>
> 2) actually I can not run anything at all in Cobalt installation (possibly
> a bad patch)
>
> To test registry in Mercury I tried to run a simple app, that gives the
> registry daemon error:
>
> ./hello
>    3"002.332| WARNING: [main] cannot connect to registry daemon
>    3"002.425| BUG: [main] initialization failed, EAGAIN
>
> The code is just that below. It makes no calls to Xenomai libs:
>
> #include <stdio.h>
> main() {
>     puts ("Hello");
>     return 0;
> }
>
> But it was compiled with Xenomai support. Makefile:
>
> target =  hello
>
> CFLAGS  := $(shell xeno-config --skin=$(skin) --cflags)
> LDFLAGS := $(shell xeno-config --skin=$(skin) --ldflags)
>
> $(target): $(target).c
>     $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
>
> The strace -f of this simple app is below.
> (After this trace is also the strace -f of latency, which runs fine in
> Mercury, but I guess you might want the starce of the not running latency
> executable in Cobalt?)
>
> $> strace -f ./hello
> execve("./hello", ["./hello"], [/* 18 vars */]) = 0
> brk(0)                                  = 0x97bf000
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7705000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=74726, ...}) = 0
> mmap2(NULL, 74726, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76f2000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/usr/xenomai/lib/libalchemy.so.0", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200=\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=66781, ...}) = 0
> mmap2(NULL, 77164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76df000
> mmap2(0xb76ec000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc) = 0xb76ec000
> mmap2(0xb76ed000, 19820, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76ed000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/usr/xenomai/lib/libcopperplate.so.0", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pW\0\0004\0\0\0"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=111928, ...}) = 0
> mmap2(NULL, 98184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76c7000
> mmap2(0xb76dd000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0xb76dd000
> mmap2(0xb76de000, 3976, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76de000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=117010, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb76c6000
> mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76ad000
> mmap2(0xb76c2000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb76c2000
> mmap2(0xb76c4000, 4608, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76c4000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
> mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76a4000
> mmap2(0xb76ab000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb76ab000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/libfuse.so.2", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`_\0\0004\0\0\0"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=211296, ...}) = 0
> mmap2(NULL, 209924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb7670000
> mmap2(0xb769a000, 40960, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a) = 0xb769a000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1446056, ...}) = 0
> mmap2(NULL, 1456504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb750c000
> mmap2(0xb766a000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e) = 0xb766a000
> mmap2(0xb766d000, 10616, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb766d000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libdl.so.2", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 512)
> = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=9844, ...}) = 0
> mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb7508000
> mmap2(0xb750a000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb750a000
> close(3)                                = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7507000
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7506000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb75066d0,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0
> mprotect(0xb750a000, 4096, PROT_READ)   = 0
> mprotect(0xb766a000, 8192, PROT_READ)   = 0
> mprotect(0xb769a000, 36864, PROT_READ)  = 0
> mprotect(0xb76ab000, 4096, PROT_READ)   = 0
> mprotect(0xb76c2000, 4096, PROT_READ)   = 0
> mprotect(0xb7724000, 4096, PROT_READ)   = 0
> munmap(0xb76f2000, 74726)               = 0
> set_tid_address(0xb7506738)             = 4037
> set_robust_list(0xb7506740, 0xc)        = 0
> futex(0xbff4bb00, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
> bff4bb10) = -1 EAGAIN (Resource temporarily unavailable)
> rt_sigaction(SIGRTMIN, {0xb76b16e0, [], SA_SIGINFO}, NULL, 8) = 0
> rt_sigaction(SIGRT_1, {0xb76b1b70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> uname({sys="Linux", node="LinuxSTR", ...}) = 0
> clock_gettime(CLOCK_MONOTONIC, {1865, 334707182}) = 0
> futex(0xb76ddaa8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> gettid()                                = 4037
> brk(0)                                  = 0x97bf000
> brk(0x97e0000)                          = 0x97e0000
> mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7702000
> mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7405000
> socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
> connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
> ECONNREFUSED (Connection refused)
> close(3)                                = 0
> rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
> vfork(Process 4038 attached
> )                                 = 4038
> [pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> [pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
> [pid  4037] nanosleep({1, 0},  <unfinished ...>
> [pid  4038] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
> "/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
> directory)
> [pid  4038] exit_group(1)               = ?
> Process 4038 detached
> <... nanosleep resumed> 0xbff4b8c4)     = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
> socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
> connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
> ECONNREFUSED (Connection refused)
> close(3)                                = 0
> rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
> vfork(Process 4039 attached
> )                                 = 4039
> [pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> [pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
> [pid  4037] nanosleep({1, 0},  <unfinished ...>
> [pid  4039] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
> "/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
> directory)
> [pid  4039] exit_group(1)               = ?
> Process 4039 detached
> <... nanosleep resumed> 0xbff4b8c4)     = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
> socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
> connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = -1
> ECONNREFUSED (Connection refused)
> close(3)                                = 0
> rt_sigaction(SIGCHLD, {SIG_IGN, [], 0}, NULL, 8) = 0
> vfork(Process 4040 attached
> )                                 = 4040
> [pid  4037] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> [pid  4037] rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
> [pid  4037] nanosleep({1, 0},  <unfinished ...>
> [pid  4040] execve("NONE/sbin/sysregd", ["sysregd", "--daemon", "--root",
> "/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No such file or
> directory)
> [pid  4040] exit_group(1)               = ?
> Process 4040 detached
> <... nanosleep resumed> 0xbff4b8c4)     = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGCHLD, {0xb76d66d0, [], SA_RESTART}, NULL, 8) = 0
> clock_gettime(CLOCK_MONOTONIC, {1868, 344105213}) = 0
> rt_sigprocmask(SIG_BLOCK, [RT_10], [], 8) = 0
> write(2, "   3\"009.398| ", 14   3"009.398| )         = 14
> write(2, "WARNING: ", 9WARNING: )                = 9
> write(2, "[main] ", 7[main] )                  = 7
> write(2, "cannot connect to registry daemo"..., 33cannot connect to
> registry daemon) = 33
> write(2, "\n", 1
> )                       = 1
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> clock_gettime(CLOCK_MONOTONIC, {1868, 344487920}) = 0
> rt_sigprocmask(SIG_BLOCK, [RT_10], [], 8) = 0
> write(2, "   3\"009.780| ", 14   3"009.780| )         = 14
> write(2, "BUG: ", 5BUG: )                    = 5
> write(2, "[main] ", 7[main] )                  = 7
> write(2, "initialization failed, EAGAIN", 29initialization failed, EAGAIN)
> = 29
> write(2, "\n", 1
> )                       = 1
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> exit_group(1)                           = ?
>
>
>
> =================
> The strace -f of latency
> =================
>
> This is the output to STDIN (so its running on Mercury but not in Cobalt)
> Below is the strace (STDERR output)
>
> strace -f latency 2> t
> == 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, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
> worst
> RTD|     33.361|     35.795|   1835.884|      47|     0|     33.361|
> 1835.884
> RTD|     33.354|     38.507|   6591.060|     219|     0|     33.354|
> 6591.060
> (...)
>
> STRACE:
>
> $> head stderr.output -n 150
> execve("/usr/xenomai/bin/latency", ["latency"], [/* 18 vars */]) = 0
> brk(0)                                  = 0x902a000
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7720000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=74726, ...}) = 0
> mmap2(NULL, 74726, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb770d000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/libfuse.so.2", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`_\0\0004\0\0\0"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=211296, ...}) = 0
> mmap2(NULL, 209924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb76d9000
> mmap2(0xb7703000, 40960, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a) = 0xb7703000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=117010, ...}) = 0
> mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76c0000
> mmap2(0xb76d5000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb76d5000
> mmap2(0xb76d7000, 4608, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76d7000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb76bf000
> mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb76b6000
> mmap2(0xb76bd000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb76bd000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libm.so.6", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2604\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=148996, ...}) = 0
> mmap2(NULL, 151680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb7690000
> mmap2(0xb76b4000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) = 0xb76b4000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1446056, ...}) = 0
> mmap2(NULL, 1456504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb752c000
> mmap2(0xb768a000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e) = 0xb768a000
> mmap2(0xb768d000, 10616, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb768d000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/i686/cmov/libdl.so.2", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 512)
> = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=9844, ...}) = 0
> mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb7528000
> mmap2(0xb752a000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb752a000
> close(3)                                = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7527000
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7526000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb75266c0,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0
> mprotect(0xb752a000, 4096, PROT_READ)   = 0
> mprotect(0xb768a000, 8192, PROT_READ)   = 0
> mprotect(0xb76b4000, 4096, PROT_READ)   = 0
> mprotect(0xb76bd000, 4096, PROT_READ)   = 0
> mprotect(0xb76d5000, 4096, PROT_READ)   = 0
> mprotect(0xb7703000, 36864, PROT_READ)  = 0
> mprotect(0xb773f000, 4096, PROT_READ)   = 0
> munmap(0xb770d000, 74726)               = 0
> set_tid_address(0xb7526728)             = 4215
> set_robust_list(0xb7526730, 0xc)        = 0
> futex(0xbffec710, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
> bffec720) = -1 EAGAIN (Resource temporarily unavailable)
> rt_sigaction(SIGRTMIN, {0xb76c46e0, [], SA_SIGINFO}, NULL, 8) = 0
> rt_sigaction(SIGRT_1, {0xb76c4b70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> uname({sys="Linux", node="LinuxSTR", ...}) = 0
> time(NULL)                              = 1425394452
> brk(0)                                  = 0x902a000
> brk(0x904b000)                          = 0x904b000
> rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM TERM], NULL, 8) = 0
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb771f000
> write(1, "== Sampling period: 100 us\n", 27) = 27
> write(1, "== Test mode: periodic user-mode"..., 69) = 69
> mlockall(MCL_CURRENT|MCL_FUTURE)        = 0
> mmap2(NULL, 8392704, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6d25000
> mprotect(0xb6d25000, 4096, PROT_NONE)   = 0
> clone(Process 4216 attached
> child_stack=0xb7525494,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0xb7525bd8, {entry_number:6, base_addr:0xb7525b70,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}, child_tidptr=0xb7525bd8) = 4216
> [pid  4215] sched_get_priority_min(SCHED_FIFO) = 1
> [pid  4215] sched_get_priority_max(SCHED_FIFO) = 99
> [pid  4215] mmap2(NULL, 8392704, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0 <unfinished ...>
> [pid  4216] set_robust_list(0xb7525be0, 0xc) = 0
> [pid  4216] prctl(PR_SET_NAME, 0xb7525328, 0x804d2e4, 0, 0xb76c1614) = 0
> [pid  4216] statfs("/dev/shm",  <unfinished ...>
> [pid  4215] <... mmap2 resumed> )       = 0xb6524000
> [pid  4216] <... statfs resumed> {f_type=0x1021994, f_bsize=4096,
> f_blocks=494345, f_bfree=494246, f_bavail=494246, f_files=221793,
> f_ffree=221780, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> [pid  4216] futex(0xb76d81a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> [pid  4216] unlink("/dev/shm/sem.dispsem-4215") = -1 ENOENT (No such file
> or directory)
> [pid  4216] gettimeofday({1425394452, 324990}, NULL) = 0
> [pid  4216] lstat64("/dev/shm/sem.i6kEQQ", 0xb7525180) = -1 ENOENT (No
> such file or directory)
> [pid  4216] open("/dev/shm/sem.i6kEQQ", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
> [pid  4216] write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16
> [pid  4216] mmap2(NULL, 16, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) =
> 0xb771e000
> [pid  4216] link("/dev/shm/sem.i6kEQQ", "/dev/shm/sem.dispsem-4215") = 0
> [pid  4216] fstat64(3, {st_mode=S_IFREG|0644, st_size=16, ...}) = 0
> [pid  4216] unlink("/dev/shm/sem.i6kEQQ") = 0
> [pid  4216] close(3)                    = 0
> [pid  4216] time(NULL)                  = 1425394452
> [pid  4216] write(1, "warming up...\n", 14) = 14
> [pid  4216] futex(0xb771e000, FUTEX_WAIT, 0, NULL <unfinished ...>
> [pid  4215] mprotect(0xb6524000, 4096, PROT_NONE) = 0
> [pid  4215] sched_get_priority_min(SCHED_FIFO) = 1
> [pid  4215] sched_get_priority_max(SCHED_FIFO) = 99
> [pid  4215] clone(Process 4217 attached
> child_stack=0xb6d24494,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0xb6d24bd8, {entry_number:6, base_addr:0xb6d24b70,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}, child_tidptr=0xb6d24bd8) = 4217
> [pid  4215] sched_setscheduler(4217, SCHED_FIFO, { 99 } <unfinished ...>
> [pid  4217] set_robust_list(0xb6d24be0, 0xc) = 0
> [pid  4217] futex(0xb6d24d84, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
> [pid  4215] <... sched_setscheduler resumed> ) = 0
> [pid  4215] futex(0xb6d24d84, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
> [pid  4217] <... futex resumed> )       = 0
> [pid  4217] futex(0xb6d24d84, FUTEX_WAKE_PRIVATE, 1) = 0
> [pid  4217] prctl(PR_SET_NAME, 0xb6d24370, 0, 0, 0xb768bff4) = 0
> [pid  4217] timerfd_create(CLOCK_MONOTONIC, 0) = 3
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 404514401}) = 0
> [pid  4217] timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0,
> 100000}, it_value={2209, 405514401}}, NULL) = 0
> [pid  4217] read(3,  <unfinished ...>
> [pid  4215] <... futex resumed> )       = 1
> [pid  4215] rt_sigtimedwait([HUP INT ALRM TERM], NULL, NULL, 8 <unfinished
> ...>
> [pid  4217] <... read resumed> "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405588957}) = 0
> [pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405652882}) = 0
> [pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405749665}) = 0
> [pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405849010}) = 0
> [pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  4217] clock_gettime(CLOCK_MONOTONIC, {2209, 405948555}) = 0
> [pid  4217] read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> (...)
> It continues ....
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 03:58 PM, Helder Daniel wrote:
> 
>     No actually, you don't need that if sysregd still appears in
>     $prefix/sbin as built.
> 
>     Please send the output of "strace -f" on the latency executable.
> 
> Ok. I tried putting sbin in the search path and gave the same error.
> 
> I am running these test now on an installation of Mercury (already on an
> AMD Sempron physical system).
> 
> /usr/xenomai/bin/latency runs fine on this installation (the issue with
> latency not running is with Cobalt installation)
> 
> I think I have 2 different problems:
> 
> 1) can not use Xenomai registry in Mercury and Cobalt.
> 
> 2) actually I can not run anything at all in Cobalt installation
> (possibly a bad patch)
> 
> To test registry in Mercury I tried to run a simple app, that gives the
> registry daemon error:
> 
> ./hello
>    3"002.332| WARNING: [main] cannot connect to registry daemon
>    3"002.425| BUG: [main] initialization failed, EAGAIN
> 

> [pid  4038] execve("NONE/sbin/sysregd", ["sysregd", "--daemon",
> "--root", "/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No

That is the issue with the registry: the installation prefix is invalid.
I suspect a wrong value passed to --prefix.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

I did not set --prefix.
I assumed the default value will be applied: /usr/xenomai

After install the xenomai tree appears to be intalled on /usr/xenomai:

/usr/xenoami/bin        with latency, ...
/usr/xenoami/include  with al the API headers
/usr/xenoami/sbin      with rsysregd, ...

On 3 March 2015 at 15:03, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/03/2015 03:58 PM, Helder Daniel wrote:
> >
> >     No actually, you don't need that if sysregd still appears in
> >     $prefix/sbin as built.
> >
> >     Please send the output of "strace -f" on the latency executable.
> >
> > Ok. I tried putting sbin in the search path and gave the same error.
> >
> > I am running these test now on an installation of Mercury (already on an
> > AMD Sempron physical system).
> >
> > /usr/xenomai/bin/latency runs fine on this installation (the issue with
> > latency not running is with Cobalt installation)
> >
> > I think I have 2 different problems:
> >
> > 1) can not use Xenomai registry in Mercury and Cobalt.
> >
> > 2) actually I can not run anything at all in Cobalt installation
> > (possibly a bad patch)
> >
> > To test registry in Mercury I tried to run a simple app, that gives the
> > registry daemon error:
> >
> > ./hello
> >    3"002.332| WARNING: [main] cannot connect to registry daemon
> >    3"002.425| BUG: [main] initialization failed, EAGAIN
> >
>
> > [pid  4038] execve("NONE/sbin/sysregd", ["sysregd", "--daemon",
> > "--root", "/var/run/xenomai/anon"], [/* 18 vars */]) = -1 ENOENT (No
>
> That is the issue with the registry: the installation prefix is invalid.
> I suspect a wrong value passed to --prefix.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 04:40 PM, Helder Daniel wrote:
> I did not set --prefix.
> I assumed the default value will be applied: /usr/xenomai

This is the case, unless something goes wrong while configuring. Can you
check the value reported in the config log when running the configure
script?

Also, which setting is output by the following command?

$ smokey --dump-conf|grep PREFIX

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

On 3 March 2015 at 15:44, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/03/2015 04:40 PM, Helder Daniel wrote:
> > I did not set --prefix.
> > I assumed the default value will be applied: /usr/xenomai
>
> This is the case, unless something goes wrong while configuring. Can you
> check the value reported in the config log when running the configure
> script?
>


this is the last 20 lines of config.log. Exit status is 0.
SO it appear that configuring was done properly.
but: #define CONFIG_XENO_PREFIX "NONE"
maybe that's the problem?

#define HAVE_SHM_UNLINK 1
#define CONFIG_XENO_VERSION_MAJOR 2
#define CONFIG_XENO_VERSION_MINOR 99
#define CONFIG_XENO_REVISION_LEVEL 12
#define CONFIG_XENO_UAPI_LEVEL 10
#define CONFIG_XENO_VERSION_STRING "3.0-rc3"
#define CONFIG_XENO_VERSION_NAME "Exact Zero"
#define CONFIG_XENO_PREFIX "NONE"
#define CONFIG_XENO_BUILD_ARGS " '--with-core=mercury' '--enable-registry'"
#define CONFIG_XENO_X86_VSYSCALL 1
#define CONFIG_SMP 1
#define CONFIG_MMU 1
#define CONFIG_XENO_DEFAULT_PERIOD 100000
#define CONFIG_XENO_TLSF 1
#define HAVE_RECENT_SETAFFINITY 1
#define CONFIG_XENO_TLS_MODEL "initial-exec"
#define HAVE_TLS 1
#define CONFIG_XENO_FORTIFY 1

configure: exit 0



> Also, which setting is output by the following command?
>
> $ smokey --dump-conf|grep PREFIX
>
>
root@LinuxSTR:~/helloXeno# smokey --dump-conf|grep PREFIX
CONFIG_XENO_PREFIX="NONE"

The same "NONE" again.

OK. So I configure explicitly the --prefix=/usr/xenomai.

Now on the config.log we have the value of the prefix:

(...)
#define CONFIG_XENO_PREFIX "/usr/xenomai"
#define CONFIG_XENO_BUILD_ARGS " '--with-core=cobalt' '--enable-registry'
'--prefix=/usr/xenomai'"
(...)

and with
root@LinuxSTR:~/helloXeno# smokey --dump-conf|grep PREFIX
CONFIG_XENO_PREFIX="/usr/xenomai"


After make install I tried to run the hello app again.
It ran.

Now there is an entry in /var/run/xenomai/ ....

I made some changes an recompile another App, than tried to run it, but now
I got several times:

sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
Transport endpoint is not connected

and then again:

   3"008.480| WARNING: [main] cannot connect to registry daemon
   3"008.891| BUG: [main] initialization failed, EAGAIN

I checked for the daemon and it is loaded:

$> ps aux | grep rsyslogd
root      2328  0.0  0.3  28840  1660 ?        Sl   16:03   0:00
/usr/sbin/rsyslogd -c5

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 05:38 PM, Helder Daniel wrote:
> 
> On 3 March 2015 at 15:44, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
>     On 03/03/2015 04:40 PM, Helder Daniel wrote:
>     > I did not set --prefix.
>     > I assumed the default value will be applied: /usr/xenomai
> 
>     This is the case, unless something goes wrong while configuring. Can you
>     check the value reported in the config log when running the configure
>     script?
> 
> 
> 
> this is the last 20 lines of config.log. Exit status is 0.
> SO it appear that configuring was done properly.

No, this does not prove that all settings were sane. $prefix is clearly
not right in this case, since CONFIG_XENO_PREFIX basically mirrors it.

> but: #define CONFIG_XENO_PREFIX "NONE"
> maybe that's the problem?

Yes, it is for sure the problem. CONFIG_XENO_PREFIX is set to the
$prefix value from the autoconf script. Please attach the file
config.log which was generated by the configure script.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 06:03 PM, Philippe Gerum wrote:
> On 03/03/2015 05:38 PM, Helder Daniel wrote:
>>
>> On 3 March 2015 at 15:44, Philippe Gerum <rpm@xenomai.org
>> <mailto:rpm@xenomai.org>> wrote:
>>
>>     On 03/03/2015 04:40 PM, Helder Daniel wrote:
>>     > I did not set --prefix.
>>     > I assumed the default value will be applied: /usr/xenomai
>>
>>     This is the case, unless something goes wrong while configuring. Can you
>>     check the value reported in the config log when running the configure
>>     script?
>>
>>
>>
>> this is the last 20 lines of config.log. Exit status is 0.
>> SO it appear that configuring was done properly.
> 
> No, this does not prove that all settings were sane. $prefix is clearly
> not right in this case, since CONFIG_XENO_PREFIX basically mirrors it.
> 
>> but: #define CONFIG_XENO_PREFIX "NONE"
>> maybe that's the problem?
> 
> Yes, it is for sure the problem. CONFIG_XENO_PREFIX is set to the
> $prefix value from the autoconf script. Please attach the file
> config.log which was generated by the configure script.
> 

In addition, please send the output of /usr/xenomai/sbin/version -a.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Ok.
Attached is the config.log generated by:

./configure --with-core=mercury --enable-registry

The output of /usr/xenomai/sbin/version -a is:

Xenomai/mercury v3.0-rc3 --
Target: i686-pc-linux-gnu
Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
Build args:  '--with-core=mercury' '--enable-registry'




On 3 March 2015 at 17:06, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/03/2015 06:03 PM, Philippe Gerum wrote:
> > On 03/03/2015 05:38 PM, Helder Daniel wrote:
> >>
> >> On 3 March 2015 at 15:44, Philippe Gerum <rpm@xenomai.org
> >> <mailto:rpm@xenomai.org>> wrote:
> >>
> >>     On 03/03/2015 04:40 PM, Helder Daniel wrote:
> >>     > I did not set --prefix.
> >>     > I assumed the default value will be applied: /usr/xenomai
> >>
> >>     This is the case, unless something goes wrong while configuring.
> Can you
> >>     check the value reported in the config log when running the
> configure
> >>     script?
> >>
> >>
> >>
> >> this is the last 20 lines of config.log. Exit status is 0.
> >> SO it appear that configuring was done properly.
> >
> > No, this does not prove that all settings were sane. $prefix is clearly
> > not right in this case, since CONFIG_XENO_PREFIX basically mirrors it.
> >
> >> but: #define CONFIG_XENO_PREFIX "NONE"
> >> maybe that's the problem?
> >
> > Yes, it is for sure the problem. CONFIG_XENO_PREFIX is set to the
> > $prefix value from the autoconf script. Please attach the file
> > config.log which was generated by the configure script.
> >
>
> In addition, please send the output of /usr/xenomai/sbin/version -a.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 47718 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150303/e2509534/attachment.obj>

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 06:23 PM, Helder Daniel wrote:
> Ok.
> Attached is the config.log generated by:
> 
> ./configure --with-core=mercury --enable-registry
> 
> The output of /usr/xenomai/sbin/version -a is:
> 
> Xenomai/mercury v3.0-rc3 -- 
> Target: i686-pc-linux-gnu
> Compiler: gcc version 4.7.2 (Debian 4.7.2-5) 
> Build args:  '--with-core=mercury' '--enable-registry'
> 

Ok, now I can reproduce this issue. For the time being, you can work
around this bug by adding --prefix=/usr/xenomai to the arguments passed
to the configure script.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 08:24 PM, Philippe Gerum wrote:
> On 03/03/2015 06:23 PM, Helder Daniel wrote:
>> Ok.
>> Attached is the config.log generated by:
>>
>> ./configure --with-core=mercury --enable-registry
>>
>> The output of /usr/xenomai/sbin/version -a is:
>>
>> Xenomai/mercury v3.0-rc3 -- 
>> Target: i686-pc-linux-gnu
>> Compiler: gcc version 4.7.2 (Debian 4.7.2-5) 
>> Build args:  '--with-core=mercury' '--enable-registry'
>>
> 
> Ok, now I can reproduce this issue. For the time being, you can work
> around this bug by adding --prefix=/usr/xenomai to the arguments passed
> to the configure script.
> 

...or any value that fits on your end.

It looks like this behavior is a regression introduced by the latest
release of the autotools, since I never stumbled upon it.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Ok, I've done that.
I configure explicitly the --prefix=/usr/xenomai.

Now on the config.log we have the value of the prefix:

(...)
#define CONFIG_XENO_PREFIX "/usr/xenomai"
#define CONFIG_XENO_BUILD_ARGS " '--with-core=cobalt' '--enable-registry'
'--prefix=/usr/xenomai'"
(...)

and with
root@LinuxSTR:~/helloXeno# smokey --dump-conf|grep PREFIX
CONFIG_XENO_PREFIX="/usr/xenomai"

After make install I tried to run the hello app again.
It ran.

Now there is an entry in /var/run/xenomai/ ....

But after I made some changes an recompile an App, and then try to run it,
I got several times:

sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
Transport endpoint is not connected

and then again:

   3"008.480| WARNING: [main] cannot connect to registry daemon
   3"008.891| BUG: [main] initialization failed, EAGAIN



On 3 March 2015 at 19:31, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/03/2015 08:24 PM, Philippe Gerum wrote:
> > On 03/03/2015 06:23 PM, Helder Daniel wrote:
> >> Ok.
> >> Attached is the config.log generated by:
> >>
> >> ./configure --with-core=mercury --enable-registry
> >>
> >> The output of /usr/xenomai/sbin/version -a is:
> >>
> >> Xenomai/mercury v3.0-rc3 --
> >> Target: i686-pc-linux-gnu
> >> Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
> >> Build args:  '--with-core=mercury' '--enable-registry'
> >>
> >
> > Ok, now I can reproduce this issue. For the time being, you can work
> > around this bug by adding --prefix=/usr/xenomai to the arguments passed
> > to the configure script.
> >
>
> ...or any value that fits on your end.
>
> It looks like this behavior is a regression introduced by the latest
> release of the autotools, since I never stumbled upon it.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 08:50 PM, Helder Daniel wrote:
> Ok, I've done that. 
> I configure explicitly the --prefix=/usr/xenomai.
> 
> Now on the config.log we have the value of the prefix:
> 
> (...)
> #define CONFIG_XENO_PREFIX "/usr/xenomai"
> #define CONFIG_XENO_BUILD_ARGS " '--with-core=cobalt'
> '--enable-registry' '--prefix=/usr/xenomai'"
> (...)
>

A recent autoconf release changed the usual behavior (once more). The
git repo now contains a fix.

> and with 
> root@LinuxSTR:~/helloXeno# smokey --dump-conf|grep PREFIX
> CONFIG_XENO_PREFIX="/usr/xenomai"
> 
> After make install I tried to run the hello app again.
> It ran.
> 
> Now there is an entry in /var/run/xenomai/ ....
> 
> But after I made some changes an recompile an App, and then try to run
> it, I got several times:
> 
> sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> Transport endpoint is not connected
> 
> and then again:
> 
>    3"008.480| WARNING: [main] cannot connect to registry daemon
>    3"008.891| BUG: [main] initialization failed, EAGAIN

Kill any running instance of sysregd, then try launching it as a
standalone daemon using:

# sysregd --linger --daemonize

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/03/2015 09:38 PM, Helder Daniel wrote:
> Done that:
> 
> $> sudo pkill sysregd
> 
> $> sudo ps aux | grep sysregd
> user      4045  0.0  0.1   3796   800 pts/1    S+   20:30   0:00 grep
> sysregd
> 
> all instances killed.
> 
> Now launch:
> 
> $> sudo /usr/xenomai/sbin/sysregd --linger --daemonize
> 
> $> sudo ps aux | grep sysregd
> root      4022  0.0  0.3   3776  1888 ?        Ssl  20:28   0:00
> /usr/xenomai/sbin/sysregd --linger --daemonize
> user      4045  0.0  0.1   3796   800 pts/1    S+   20:30   0:00 grep
> sysregd
> 
> Daemon running.
> 
> Now tried to run app and receive the same error:
> 
> ./hello
> sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> Transport endpoint is not connected
> sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> Transport endpoint is not connected
> sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> Transport endpoint is not connected
>    3"006.383| WARNING: [main] cannot connect to registry daemon
>    3"006.574| BUG: [main] initialization failed, EAGAIN
> 

The only plausible scenario for this issue is that sysregd got killed
(e.g. SIGKILL or SIGHUP, not SIGTERM which currently leads to a graceful
exit) while it was running, which caused the FUSE-based anon/system
mountpoint to be left over.

To fix this, you can unmount the system mount point manually before
starting sysregd again:

# fusermount -u /var/run/xenomai/anon/system

We can probably do better with graceful exit and cleaning up left overs.
I'll look at this.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Ok.
This way I can recover registry.
I did not find yet when and why registry crashes.
If I found the scenario I'll report it.

Meanwhile I am having roubles binding to a semaphore created in one
process, from another process.
I used a simple demo app to show what is happening (full source code
attached)

From one process (creator.c) a semaphore is created and binded by its
registry name "namedSem":

rt_task_shadow (&task, "creatorTask", 20, 0);
rt_sem_create(&sem, "namedSem", 0, S_FIFO);
rt_sem_bind(&sem, "namedSem", TM_INFINITE);
for (;;) sleep (100);

So all ok here.

Now keeping creator.c running in an xterm and trying to bind to this
semaphore from another process (binder.c), from another xterm, it does not
work:

rt_task_shadow (&task, "binderTask", 20, 0);
rt_sem_bind(&sem, "namedSem", TM_INFINITE);

rt_sem_bind() never binds to the semaphore "namedSem".
It seams it does not find it.
If a timeout is set:

err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);

it returns with error -110 (ETIMEDOUT)

But the semaphore exists in registry:

$> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem
=0

I think on version 2.5.x a named object is global to the system.
So when creating a semaphore named "namedSem" by a process it is visible
for all other processes.

Maybe in 3.x semaphores (and other objects) are local to processes?
Since they are stored in the registry under the pid of the creator process?

Maybe this would explain why it is possible to bind from the same process
but not from another process with the same code:

rt_sem_bind(&sem, "namedSem", TM_INFINITE);

If this is so how to bind to an object existing in the xenomai registry
(created by another process)?
The second argument of rt_xxxx_bind() should include something like the PID
of the creator process?

PS:
I am using Mercury so no /proc/xenomai support:

/usr/xenomai/sbin/version -a
Xenomai/mercury v3.0-rc3 --
Target: i686-pc-linux-gnu
Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
Build args:  '--with-core=mercury' '--enable-registry'
'--prefix=/usr/xenomai'




On 4 March 2015 at 08:40, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/03/2015 09:38 PM, Helder Daniel wrote:
> > Done that:
> >
> > $> sudo pkill sysregd
> >
> > $> sudo ps aux | grep sysregd
> > user      4045  0.0  0.1   3796   800 pts/1    S+   20:30   0:00 grep
> > sysregd
> >
> > all instances killed.
> >
> > Now launch:
> >
> > $> sudo /usr/xenomai/sbin/sysregd --linger --daemonize
> >
> > $> sudo ps aux | grep sysregd
> > root      4022  0.0  0.3   3776  1888 ?        Ssl  20:28   0:00
> > /usr/xenomai/sbin/sysregd --linger --daemonize
> > user      4045  0.0  0.1   3796   800 pts/1    S+   20:30   0:00 grep
> > sysregd
> >
> > Daemon running.
> >
> > Now tried to run app and receive the same error:
> >
> > ./hello
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> >    3"006.383| WARNING: [main] cannot connect to registry daemon
> >    3"006.574| BUG: [main] initialization failed, EAGAIN
> >
>
> The only plausible scenario for this issue is that sysregd got killed
> (e.g. SIGKILL or SIGHUP, not SIGTERM which currently leads to a graceful
> exit) while it was running, which caused the FUSE-based anon/system
> mountpoint to be left over.
>
> To fix this, you can unmount the system mount point manually before
> starting sysregd again:
>
> # fusermount -u /var/run/xenomai/anon/system
>
> We can probably do better with graceful exit and cleaning up left overs.
> I'll look at this.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xenomaiRegistryCheck.tar.gz
Type: application/x-gzip
Size: 1425 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150304/2070e2ec/attachment.bin>

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/04/2015 12:21 PM, Helder Daniel wrote:
> Ok.
> This way I can recover registry.
> I did not find yet when and why registry crashes.
> If I found the scenario I'll report it.
> 
> Meanwhile I am having roubles binding to a semaphore created in one
> process, from another process.
> I used a simple demo app to show what is happening (full source code
> attached)
> 
> From one process (creator.c) a semaphore is created and binded by its
> registry name "namedSem":
> 
> rt_task_shadow (&task, "creatorTask", 20, 0); 
> rt_sem_create(&sem, "namedSem", 0, S_FIFO);
> rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> for (;;) sleep (100);
> 
> So all ok here.
> 
> Now keeping creator.c running in an xterm and trying to bind to this
> semaphore from another process (binder.c), from another xterm, it does
> not work:
> 
> rt_task_shadow (&task, "binderTask", 20, 0); 
> rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> 
> rt_sem_bind() never binds to the semaphore "namedSem".
> It seams it does not find it.
> If a timeout is set:
> 
> err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> 
> it returns with error -110 (ETIMEDOUT)
> 
> But the semaphore exists in registry:
> 
> $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem 
> =0
> 
> I think on version 2.5.x a named object is global to the system.
> So when creating a semaphore named "namedSem" by a process it is visible
> for all other processes.
> 
> Maybe in 3.x semaphores (and other objects) are local to processes?
> Since they are stored in the registry under the pid of the creator process?

With 3.x, --enable-pshared must be passed to enable object sharing
between processes. The actual registry is not maintained in kernel space
anymore, so the support libraries have to know whether they should
maintain it.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

I reinstalled xenomai with pshared enabled but it still do not work.
Second process gives now a segmentation fault when trying to bind.
If executed with --no-registry (it will not bind of course) but it does not
segment fault also.

/usr/xenomai/sbin/version -a
Xenomai/mercury v3.0-rc3 --
Target: i686-pc-linux-gnu
Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
Build args:  '--with-core=mercury' '--enable-registry' '--enable-pshared'
'--prefix=/usr/xenomai'


On 4 March 2015 at 11:40, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/04/2015 12:21 PM, Helder Daniel wrote:
> > Ok.
> > This way I can recover registry.
> > I did not find yet when and why registry crashes.
> > If I found the scenario I'll report it.
> >
> > Meanwhile I am having roubles binding to a semaphore created in one
> > process, from another process.
> > I used a simple demo app to show what is happening (full source code
> > attached)
> >
> > From one process (creator.c) a semaphore is created and binded by its
> > registry name "namedSem":
> >
> > rt_task_shadow (&task, "creatorTask", 20, 0);
> > rt_sem_create(&sem, "namedSem", 0, S_FIFO);
> > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> > for (;;) sleep (100);
> >
> > So all ok here.
> >
> > Now keeping creator.c running in an xterm and trying to bind to this
> > semaphore from another process (binder.c), from another xterm, it does
> > not work:
> >
> > rt_task_shadow (&task, "binderTask", 20, 0);
> > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >
> > rt_sem_bind() never binds to the semaphore "namedSem".
> > It seams it does not find it.
> > If a timeout is set:
> >
> > err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >
> > it returns with error -110 (ETIMEDOUT)
> >
> > But the semaphore exists in registry:
> >
> > $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem
> > =0
> >
> > I think on version 2.5.x a named object is global to the system.
> > So when creating a semaphore named "namedSem" by a process it is visible
> > for all other processes.
> >
> > Maybe in 3.x semaphores (and other objects) are local to processes?
> > Since they are stored in the registry under the pid of the creator
> process?
>
> With 3.x, --enable-pshared must be passed to enable object sharing
> between processes. The actual registry is not maintained in kernel space
> anymore, so the support libraries have to know whether they should
> maintain it.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/04/2015 03:25 PM, Helder Daniel wrote:
> I reinstalled xenomai with pshared enabled but it still do not work.
> Second process gives now a segmentation fault when trying to bind.
> If executed with --no-registry (it will not bind of course) but it does
> not segment fault also.
> 

In case of a segfault,  run the application over gdb, so that you can
provide the backtrace. Building with --enable-debug will help.

> /usr/xenomai/sbin/version -a
> Xenomai/mercury v3.0-rc3 -- 
> Target: i686-pc-linux-gnu
> Compiler: gcc version 4.7.2 (Debian 4.7.2-5) 
> Build args:  '--with-core=mercury' '--enable-registry'
> '--enable-pshared' '--prefix=/usr/xenomai'
> 
> 
> On 4 March 2015 at 11:40, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
>     On 03/04/2015 12:21 PM, Helder Daniel wrote:
>     > Ok.
>     > This way I can recover registry.
>     > I did not find yet when and why registry crashes.
>     > If I found the scenario I'll report it.
>     >
>     > Meanwhile I am having roubles binding to a semaphore created in one
>     > process, from another process.
>     > I used a simple demo app to show what is happening (full source code
>     > attached)
>     >
>     > From one process (creator.c) a semaphore is created and binded by its
>     > registry name "namedSem":
>     >
>     > rt_task_shadow (&task, "creatorTask", 20, 0);
>     > rt_sem_create(&sem, "namedSem", 0, S_FIFO);
>     > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
>     > for (;;) sleep (100);
>     >
>     > So all ok here.
>     >
>     > Now keeping creator.c running in an xterm and trying to bind to this
>     > semaphore from another process (binder.c), from another xterm, it does
>     > not work:
>     >
>     > rt_task_shadow (&task, "binderTask", 20, 0);
>     > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
>     >
>     > rt_sem_bind() never binds to the semaphore "namedSem".
>     > It seams it does not find it.
>     > If a timeout is set:
>     >
>     > err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);
>     >
>     > it returns with error -110 (ETIMEDOUT)
>     >
>     > But the semaphore exists in registry:
>     >
>     > $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem
>     > =0
>     >
>     > I think on version 2.5.x a named object is global to the system.
>     > So when creating a semaphore named "namedSem" by a process it is
>     visible
>     > for all other processes.
>     >
>     > Maybe in 3.x semaphores (and other objects) are local to processes?
>     > Since they are stored in the registry under the pid of the creator
>     process?
> 
>     With 3.x, --enable-pshared must be passed to enable object sharing
>     between processes. The actual registry is not maintained in kernel space
>     anymore, so the support libraries have to know whether they should
>     maintain it.
> 
>     --
>     Philippe.
> 
> 
> 
> 
> -- 
> Helder Daniel
> UALG - FCT
> DEEI
> 
> http://w3.ualg.pt/~hdaniel


-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

I reinstall xenomai enabling debug support:

/usr/xenomai/sbin/version -a
Xenomai/mercury v3.0-rc3 --
Target: i686-pc-linux-gnu
Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
Build args:  '--with-core=mercury' '--enable-registry' '--enable-pshared'
'--prefix=/usr/xenomai' '--enable-debug'

Then I removed all the code from the second process (binder.c), now main()
its empty.

Running binder.c while creator.c is running, still gives a segmentation
fault.

Since now there is no code in binder.c I compile it with no Xenomai
support, just gcc binder.c -o binder.
This way it runs (of course does nothing) without segmentation fault.

So it must be something in the initialization of the Xenomai app.
And only happens when another Xenomai app (creator.c) is running.

I did not backtrace it with gdbg yet, but I recompile it (main() still
empty) with Xenomai support and make an strace -f (while creator.c is still
running).
It seems that the segmentation fault happens when trying to lock memory
pages in RAM (called by the initialization code):

execve("./binder", ["./binder"], [/* 18 vars */]) = 0
brk(0)                                  = 0x87b6000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7791000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=65962, ...}) = 0
mmap2(NULL, 65962, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7780000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/usr/xenomai/lib/libalchemy.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pA\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=287215, ...}) = 0
mmap2(NULL, 65100, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7770000
mmap2(0xb777f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb777f000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/usr/xenomai/lib/libcopperplate.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
a\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=495119, ...}) = 0
mmap2(NULL, 129532, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7750000
mmap2(0xb776d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0xb776d000
mmap2(0xb776f000, 2556, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb776f000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117010, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb774f000
mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7736000
mmap2(0xb774b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb774b000
mmap2(0xb774d000, 4608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb774d000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb772d000
mmap2(0xb7734000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb7734000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/libfuse.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`_\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=211296, ...}) = 0
mmap2(NULL, 209924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76f9000
mmap2(0xb7723000, 40960, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a) = 0xb7723000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1446056, ...}) = 0
mmap2(NULL, 1460600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7594000
mmap2(0xb76f3000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e) = 0xb76f3000
mmap2(0xb76f6000, 10616, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76f6000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/i386-linux-gnu/i686/cmov/libdl.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9844, ...}) = 0
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7590000
mmap2(0xb7592000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7592000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb758f000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb758e000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb758e6d0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
mprotect(0xb7592000, 4096, PROT_READ)   = 0
mprotect(0xb76f3000, 8192, PROT_READ)   = 0
mprotect(0xb7723000, 36864, PROT_READ)  = 0
mprotect(0xb7734000, 4096, PROT_READ)   = 0
mprotect(0xb774b000, 4096, PROT_READ)   = 0
mprotect(0xb77b0000, 4096, PROT_READ)   = 0
munmap(0xb7780000, 65962)               = 0
set_tid_address(0xb758e738)             = 3907
set_robust_list(0xb758e740, 0xc)        = 0
futex(0xbfbbcc90, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
bfbbcca0) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb773a6e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb773ab70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="debian", ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {225, 53614430}) = 0
futex(0xb776e504, FUTEX_WAKE_PRIVATE, 2147483647) = 0
gettid()                                = 3907
brk(0)                                  = 0x87b6000
brk(0x87d7000)                          = 0x87d7000
statfs("/dev/shm/", {f_type=0x1021994, f_bsize=4096, f_blocks=70795,
f_bfree=70480, f_bavail=70480, f_files=64349, f_ffree=64342, f_fsid={0, 0},
f_namelen=255, f_frsize=4096}) = 0
futex(0xb7735200, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/dev/shm/xeno:(null).main-heap", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC,
0600) = 3
flock(3, LOCK_EX)                       = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=1059164, ...}) = 0
mmap2(NULL, 1059164, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xb748b000
kill(3903, SIG_0)                       = 0
flock(3, LOCK_UN)                       = 0
close(3)                                = 0
socket(PF_FILE, SOCK_SEQPACKET, 0)      = 3
connect(3, {sa_family=AF_FILE, path=@"DEF365BC-xenomai"}, 19) = 0
recv(3, "/var/run/xenomai/anon/3907\0", 4096, 0) = 27
clock_gettime(CLOCK_MONOTONIC, {225, 54779417}) = 0
mmap2(NULL, 69632, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb7780000
mprotect(0xb7780000, 4096, PROT_NONE)   = 0
clone(Process 3908 attached
child_stack=0xb7790484,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb7790bd8, {entry_number:6, base_addr:0xb7790b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}, child_tidptr=0xb7790bd8) = 3908
[pid  3907] futex(0xb776e94c, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  3908] set_robust_list(0xb7790be0, 0xc) = 0
[pid  3908] lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid  3908] lstat64("/var/run", {st_mode=S_IFLNK|0777, st_size=4, ...}) = 0
[pid  3908] readlink("/var/run", "/run", 4095) = 4
[pid  3908] lstat64("/run", {st_mode=S_IFDIR|0755, st_size=880, ...}) = 0
[pid  3908] lstat64("/run/xenomai", {st_mode=S_IFDIR|0755, st_size=60,
...}) = 0
[pid  3908] lstat64("/run/xenomai/anon", {st_mode=S_IFDIR|0755,
st_size=180, ...}) = 0
[pid  3908] lstat64("/run/xenomai/anon/3907", {st_mode=S_IFDIR|0755,
st_size=40, ...}) = 0
[pid  3908] open("/dev/null", O_RDWR|O_LARGEFILE) = 4
[pid  3908] close(4)                    = 0
[pid  3908] stat64("/run/xenomai/anon/3907", {st_mode=S_IFDIR|0755,
st_size=40, ...}) = 0
[pid  3908] open("/run/xenomai/anon/3907",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
[pid  3908] getdents64(4, /* 2 entries */, 32768) = 48
[pid  3908] getdents64(4, /* 0 entries */, 32768) = 0
[pid  3908] close(4)                    = 0
[pid  3908] open("/dev/fuse", O_RDWR|O_LARGEFILE) = 4
[pid  3908] getgid32()                  = 0
[pid  3908] getuid32()                  = 0
[pid  3908] mount("binder", "/run/xenomai/anon/3907", "fuse.binder",
MS_NOSUID|MS_NODEV, "default_permissions,fd=4,rootmod"...) = 0
[pid  3908] geteuid32()                 = 0
[pid  3908] lstat64("/run", {st_mode=S_IFDIR|0755, st_size=880, ...}) = 0
[pid  3908] lstat64("/run/xenomai", {st_mode=S_IFDIR|0755, st_size=60,
...}) = 0
[pid  3908] lstat64("/run/xenomai/anon", {st_mode=S_IFDIR|0755,
st_size=180, ...}) = 0
[pid  3908] lstat64("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=12, ...}) =
0
[pid  3908] getuid32()                  = 0
[pid  3908] mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb748a000
[pid  3908] rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid  3908] rt_sigaction(SIGHUP, {0xb7712ed0, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid  3908] rt_sigaction(SIGINT, {0xb7712ed0, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid  3908] rt_sigaction(SIGTERM, {0xb7712ed0, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGPIPE, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid  3908] rt_sigaction(SIGPIPE, {SIG_IGN, [], 0}, NULL, 8) = 0
[pid  3908] mmap2(NULL, 139264, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7468000
[pid  3908] read(4,
"8\0\0\0\32\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
135168) = 56
[pid  3908] rt_sigaction(SIGTERM, {SIG_DFL, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGHUP, {SIG_DFL, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
[pid  3908] rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
[pid  3908] futex(0xb776e94c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  3907] <... futex resumed> )       = 0
[pid  3907] sched_get_priority_max(SCHED_FIFO) = 99
[pid  3907] rt_sigaction(SIGRT_12, {0xb775aa90, [], SA_RESTART}, NULL, 8) =
0
[pid  3907] rt_sigaction(SIGRT_13, {0xb775ab50, [], SA_RESTART}, NULL, 8) =
0
[pid  3907] rt_sigaction(SIGRT_10, {0xb775ab40, [], SA_RESTART}, NULL, 8) =
0
[pid  3907] rt_sigaction(SIGRT_11, {0xb775aad0, [], SA_RESTART}, NULL, 8) =
0
[pid  3907] rt_sigaction(SIGRT_15, {0xb775aad0, [], SA_RESTART}, NULL, 8) =
0
[pid  3907] rt_sigprocmask(SIG_BLOCK, [RT_14], NULL, 8) = 0
[pid  3907] mmap2(NULL, 69632, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb7457000
[pid  3907] mprotect(0xb7457000, 4096, PROT_NONE) = 0
[pid  3907] clone(Process 3909 attached
child_stack=0xb7467484,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb7467bd8, {entry_number:6, base_addr:0xb7467b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}, child_tidptr=0xb7467bd8) = 3909
[pid  3907] futex(0xbfbbca38, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  3908] writev(4, [{"(\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0", 16},
{"\7\0\0\0\22\0\0\0\0\0\2\0\20\0\0\0\0\0\0\0\0\0\2\0", 24}], 2) = 40
[pid  3908] read(4,  <unfinished ...>
[pid  3909] set_robust_list(0xb7467be0, 0xc) = 0
[pid  3909] gettid()                    = 3909
[pid  3909] prctl(PR_SET_NAME, 0xb7767adf, 0, 0, 0) = 0
[pid  3909] futex(0xbfbbca38, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  3907] <... futex resumed> )       = 0
[pid  3907] gettid()                    = 3907
[pid  3907] prctl(PR_SET_NAME, 0xb74935a8, 0, 0, 0) = 0
[pid  3907] rt_sigprocmask(SIG_BLOCK, [RT_11 RT_15], NULL, 8) = 0
[pid  3907] timer_create(0xfffffffe /* CLOCK_??? */, {(nil), 45,
SIGEV_THREAD_ID, {3907}}, {0x1}) = 0
[pid  3907] mlockall(MCL_CURRENT|MCL_FUTURE) = 0
[pid  3907] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid  3908] +++ killed by SIGSEGV +++
[pid  3909] +++ killed by SIGSEGV +++










it still gives a segmentation fault

On 4 March 2015 at 14:29, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/04/2015 03:25 PM, Helder Daniel wrote:
> > I reinstalled xenomai with pshared enabled but it still do not work.
> > Second process gives now a segmentation fault when trying to bind.
> > If executed with --no-registry (it will not bind of course) but it does
> > not segment fault also.
> >
>
> In case of a segfault,  run the application over gdb, so that you can
> provide the backtrace. Building with --enable-debug will help.
>
> > /usr/xenomai/sbin/version -a
> > Xenomai/mercury v3.0-rc3 --
> > Target: i686-pc-linux-gnu
> > Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
> > Build args:  '--with-core=mercury' '--enable-registry'
> > '--enable-pshared' '--prefix=/usr/xenomai'
> >
> >
> > On 4 March 2015 at 11:40, Philippe Gerum <rpm@xenomai.org
> > <mailto:rpm@xenomai.org>> wrote:
> >
> >     On 03/04/2015 12:21 PM, Helder Daniel wrote:
> >     > Ok.
> >     > This way I can recover registry.
> >     > I did not find yet when and why registry crashes.
> >     > If I found the scenario I'll report it.
> >     >
> >     > Meanwhile I am having roubles binding to a semaphore created in one
> >     > process, from another process.
> >     > I used a simple demo app to show what is happening (full source
> code
> >     > attached)
> >     >
> >     > From one process (creator.c) a semaphore is created and binded by
> its
> >     > registry name "namedSem":
> >     >
> >     > rt_task_shadow (&task, "creatorTask", 20, 0);
> >     > rt_sem_create(&sem, "namedSem", 0, S_FIFO);
> >     > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >     > for (;;) sleep (100);
> >     >
> >     > So all ok here.
> >     >
> >     > Now keeping creator.c running in an xterm and trying to bind to
> this
> >     > semaphore from another process (binder.c), from another xterm, it
> does
> >     > not work:
> >     >
> >     > rt_task_shadow (&task, "binderTask", 20, 0);
> >     > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >     >
> >     > rt_sem_bind() never binds to the semaphore "namedSem".
> >     > It seams it does not find it.
> >     > If a timeout is set:
> >     >
> >     > err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >     >
> >     > it returns with error -110 (ETIMEDOUT)
> >     >
> >     > But the semaphore exists in registry:
> >     >
> >     > $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem
> >     > =0
> >     >
> >     > I think on version 2.5.x a named object is global to the system.
> >     > So when creating a semaphore named "namedSem" by a process it is
> >     visible
> >     > for all other processes.
> >     >
> >     > Maybe in 3.x semaphores (and other objects) are local to processes?
> >     > Since they are stored in the registry under the pid of the creator
> >     process?
> >
> >     With 3.x, --enable-pshared must be passed to enable object sharing
> >     between processes. The actual registry is not maintained in kernel
> space
> >     anymore, so the support libraries have to know whether they should
> >     maintain it.
> >
> >     --
> >     Philippe.
> >
> >
> >
> >
> > --
> > Helder Daniel
> > UALG - FCT
> > DEEI
> >
> > http://w3.ualg.pt/~hdaniel
>
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/04/2015 04:26 PM, Helder Daniel wrote:
> I reinstall xenomai enabling debug support:
> 
> /usr/xenomai/sbin/version -a
> Xenomai/mercury v3.0-rc3 -- 
> Target: i686-pc-linux-gnu
> Compiler: gcc version 4.7.2 (Debian 4.7.2-5) 
> Build args:  '--with-core=mercury' '--enable-registry'
> '--enable-pshared' '--prefix=/usr/xenomai' '--enable-debug'
>

Looks good.

> Then I removed all the code from the second process (binder.c), now
> main() its empty.
> 
> Running binder.c while creator.c is running, still gives a segmentation
> fault.
> 
> Since now there is no code in binder.c I compile it with no Xenomai
> support, just gcc binder.c -o binder.
> This way it runs (of course does nothing) without segmentation fault.
> 
> So it must be something in the initialization of the Xenomai app.

Ack.

> And only happens when another Xenomai app (creator.c) is running.
>

In shared mode, it seems.

> I did not backtrace it with gdbg yet, but I recompile it (main() still
> empty) with Xenomai support and make an strace -f (while creator.c is
> still running).

gdb will pinpoint the exact location of this fault.

> It seems that the segmentation fault happens when trying to lock memory
> pages in RAM (called by the initialization code):
> 
> [pid  3907] mlockall(MCL_CURRENT|MCL_FUTURE) = 0
> [pid  3907] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> [pid  3908] +++ killed by SIGSEGV +++
> [pid  3909] +++ killed by SIGSEGV +++

strace only reports system calls, with mlockall returning a success
status, so the segfault happens later.

I'll build your test case and dig this issue tomorrow. Thanks for your
patient reports, this will help fixing up the rough edges.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

ok.
Here is the backtrace of "binder" process with gdb:

root@debian:~/xenomaiRegistryCheck# gdb binder
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/xenomaiRegistryCheck/binder...done.
(gdb) r
Starting program: /root/xenomaiRegistryCheck/binder
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xb7fdeb70 (LWP 4409)]
[New Thread 0xb7cb5b70 (LWP 4410)]

Program received signal SIGSEGV, Segmentation fault.
0xb76cdc10 in ?? ()
(gdb) bt
#0  0xb76cdc10 in ?? ()
#1  0xb7fafa29 in hash_search (t=0xb7cd9110, key=key@entry=0xb7fca217,
len=12)
    at hash.c:193
#2  0xb7fa5015 in cluster_init (c=c@entry=0xb7fcddfc,
    name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:118
#3  0xb7fa526a in syncluster_init (sc=0xb7fcddfc,
    name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:214
#4  0xb7fc25c9 in alchemy_init () at init.c:102
#5  0xb7fa6ea3 in copperplate_init (argcp=argcp@entry=0xbffffc10,
    argvp=argvp@entry=0xbffffc14) at init.c:635
#6  0xb7fa75d3 in copperplate_main (argc=1, argv=0xbffffcb4) at main.c:27
#7  0xb7df8e46 in __libc_start_main ()
   from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#8  0x080484f1 in _start ()
(gdb)




On 4 March 2015 at 17:18, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/04/2015 04:26 PM, Helder Daniel wrote:
> > I reinstall xenomai enabling debug support:
> >
> > /usr/xenomai/sbin/version -a
> > Xenomai/mercury v3.0-rc3 --
> > Target: i686-pc-linux-gnu
> > Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
> > Build args:  '--with-core=mercury' '--enable-registry'
> > '--enable-pshared' '--prefix=/usr/xenomai' '--enable-debug'
> >
>
> Looks good.
>
> > Then I removed all the code from the second process (binder.c), now
> > main() its empty.
> >
> > Running binder.c while creator.c is running, still gives a segmentation
> > fault.
> >
> > Since now there is no code in binder.c I compile it with no Xenomai
> > support, just gcc binder.c -o binder.
> > This way it runs (of course does nothing) without segmentation fault.
> >
> > So it must be something in the initialization of the Xenomai app.
>
> Ack.
>
> > And only happens when another Xenomai app (creator.c) is running.
> >
>
> In shared mode, it seems.
>
> > I did not backtrace it with gdbg yet, but I recompile it (main() still
> > empty) with Xenomai support and make an strace -f (while creator.c is
> > still running).
>
> gdb will pinpoint the exact location of this fault.
>
> > It seems that the segmentation fault happens when trying to lock memory
> > pages in RAM (called by the initialization code):
> >
> > [pid  3907] mlockall(MCL_CURRENT|MCL_FUTURE) = 0
> > [pid  3907] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > [pid  3908] +++ killed by SIGSEGV +++
> > [pid  3909] +++ killed by SIGSEGV +++
>
> strace only reports system calls, with mlockall returning a success
> status, so the segfault happens later.
>
> I'll build your test case and dig this issue tomorrow. Thanks for your
> patient reports, this will help fixing up the rough edges.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/05/2015 12:30 AM, Helder Daniel wrote:
> ok.
> Here is the backtrace of "binder" process with gdb:
>

<snip>

> Program received signal SIGSEGV, Segmentation fault.
> 0xb76cdc10 in ?? ()
> (gdb) bt
> #0  0xb76cdc10 in ?? ()
> #1  0xb7fafa29 in hash_search (t=0xb7cd9110, key=key@entry=0xb7fca217,
> len=12)
>     at hash.c:193
> #2  0xb7fa5015 in cluster_init (c=c@entry=0xb7fcddfc, 
>     name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:118
> #3  0xb7fa526a in syncluster_init (sc=0xb7fcddfc, 
>     name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:214
> #4  0xb7fc25c9 in alchemy_init () at init.c:102
> #5  0xb7fa6ea3 in copperplate_init (argcp=argcp@entry=0xbffffc10, 
>     argvp=argvp@entry=0xbffffc14) at init.c:635
> #6  0xb7fa75d3 in copperplate_main (argc=1, argv=0xbffffcb4) at main.c:27
> #7  0xb7df8e46 in __libc_start_main ()
>    from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #8  0x080484f1 in _start ()
> (gdb) 
> 
> 

This is now fixed in -next branch, will be part of -rc4.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Hi Philippe,

I tried on Mercury and Cobalt and now it binds fine.
Thank you.

However sometimes after interrupting a task it is needed to restart
registry again:

pkill sysregd
fusermount -u /var/run/xenomai/anon/system
/usr/xenomai/sbin/sysregd --linger --daemonize




On 15 March 2015 at 16:20, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/05/2015 12:30 AM, Helder Daniel wrote:
> > ok.
> > Here is the backtrace of "binder" process with gdb:
> >
>
> <snip>
>
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xb76cdc10 in ?? ()
> > (gdb) bt
> > #0  0xb76cdc10 in ?? ()
> > #1  0xb7fafa29 in hash_search (t=0xb7cd9110, key=key@entry=0xb7fca217,
> > len=12)
> >     at hash.c:193
> > #2  0xb7fa5015 in cluster_init (c=c@entry=0xb7fcddfc,
> >     name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:118
> > #3  0xb7fa526a in syncluster_init (sc=0xb7fcddfc,
> >     name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:214
> > #4  0xb7fc25c9 in alchemy_init () at init.c:102
> > #5  0xb7fa6ea3 in copperplate_init (argcp=argcp@entry=0xbffffc10,
> >     argvp=argvp@entry=0xbffffc14) at init.c:635
> > #6  0xb7fa75d3 in copperplate_main (argc=1, argv=0xbffffcb4) at main.c:27
> > #7  0xb7df8e46 in __libc_start_main ()
> >    from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> > #8  0x080484f1 in _start ()
> > (gdb)
> >
> >
>
> This is now fixed in -next branch, will be part of -rc4.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/16/2015 07:58 PM, Helder Daniel wrote:
> Hi Philippe,
> 
> I tried on Mercury and Cobalt and now it binds fine.
> Thank you.
> 
> However sometimes after interrupting a task it is needed to restart
> registry again:
> 
> pkill sysregd
> fusermount -u /var/run/xenomai/anon/system
> /usr/xenomai/sbin/sysregd --linger --daemonize
> 
> 

That should not be the case. What is the issue requiring to restart
sysregd manually?

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/16/2015 08:21 PM, Philippe Gerum wrote:
> On 03/16/2015 07:58 PM, Helder Daniel wrote:
>> Hi Philippe,
>>
>> I tried on Mercury and Cobalt and now it binds fine.
>> Thank you.
>>
>> However sometimes after interrupting a task it is needed to restart
>> registry again:
>>
>> pkill sysregd
>> fusermount -u /var/run/xenomai/anon/system
>> /usr/xenomai/sbin/sysregd --linger --daemonize
>>
>>
> 
> That should not be the case. What is the issue requiring to restart
> sysregd manually?
> 

Ok, got it. This is a Cobalt-specific issue, with the kernel-side
registry leaking IPC object handles.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

ok

On 17 March 2015 at 17:10, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/17/2015 06:06 PM, Helder Daniel wrote:
> > I am sorry I just found now.
> > It still happens with Mercury (with the configuration described in the
> > previous email)
> >
> > When I compiled another app and try to run it I got the same error:
> >
> > root@debian:~/09-portAccessSyncTwoAppsC++# ./writeport
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
> > Transport endpoint is not connected
> >    3"012.188| WARNING: [main] cannot connect to registry daemon
> >    3"012.188| BUG: [main] initialization failed, EAGAIN
>
> Ok. This one is different from the ENOMEM issue, which is
> Cobalt-specific. The problem with mounting the anon/system root is a
> FUSE issue, which still needs a work around it seems.
>
> --
> Philippe.
>

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/17/2015 06:19 PM, Helder Daniel wrote:
> ok
> 
> On 17 March 2015 at 17:10, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
>     On 03/17/2015 06:06 PM, Helder Daniel wrote:
>     > I am sorry I just found now.
>     > It still happens with Mercury (with the configuration described in the
>     > previous email)
>     >
>     > When I compiled another app and try to run it I got the same error:
>     >
>     > root@debian:~/09-portAccessSyncTwoAppsC++# ./writeport
>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>     > Transport endpoint is not connected
>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>     > Transport endpoint is not connected
>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>     > Transport endpoint is not connected
>     >    3"012.188| WARNING: [main] cannot connect to registry daemon
>     >    3"012.188| BUG: [main] initialization failed, EAGAIN
> 
>     Ok. This one is different from the ENOMEM issue, which is
>     Cobalt-specific. The problem with mounting the anon/system root is a
>     FUSE issue, which still needs a work around it seems.
> 

The ENOMEM issue is now fixed in -next. I'll tackle the C++ parsing
problem with libtrank next.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/19/2015 06:23 PM, Philippe Gerum wrote:
> On 03/17/2015 06:19 PM, Helder Daniel wrote:
>> ok
>>
>> On 17 March 2015 at 17:10, Philippe Gerum <rpm@xenomai.org
>> <mailto:rpm@xenomai.org>> wrote:
>>
>>     On 03/17/2015 06:06 PM, Helder Daniel wrote:
>>     > I am sorry I just found now.
>>     > It still happens with Mercury (with the configuration described in the
>>     > previous email)
>>     >
>>     > When I compiled another app and try to run it I got the same error:
>>     >
>>     > root@debian:~/09-portAccessSyncTwoAppsC++# ./writeport
>>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>>     > Transport endpoint is not connected
>>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>>     > Transport endpoint is not connected
>>     > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"):
>>     > Transport endpoint is not connected
>>     >    3"012.188| WARNING: [main] cannot connect to registry daemon
>>     >    3"012.188| BUG: [main] initialization failed, EAGAIN
>>
>>     Ok. This one is different from the ENOMEM issue, which is
>>     Cobalt-specific. The problem with mounting the anon/system root is a
>>     FUSE issue, which still needs a work around it seems.
>>
> 
> The ENOMEM issue is now fixed in -next. I'll tackle the C++ parsing
> problem with libtrank next.
> 

This commit in -next fixes the link stage for the readport/writeport test.

http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=f537649c1b69a4f7b6d8f22ef344faf3414fe079

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Ok,

but now I am compiling a module to write for an I/O port (code below)
With the previous version of next branch I can compile it without any
error, insert it check that it is working fine by reading te I/O port from
an user space app, but with this new version, when compiling the module, I
get:

 CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
In file included from include/xenomai/rtdm/driver.h:43:0,
                 from
/mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
cobalt/uapi/corectl.h: No such file or directory
 #include <cobalt/uapi/corectl.h>
                                 ^
compilation terminated.

The makefile is just:

obj-m += writeportK.o

$(eval EXTRA_CFLAGS := $(shell xeno-config --kcflags))

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules


And the code of the module:

#include <linux/kernel.h>
#include <linux/module.h>
#include <rtdm/driver.h>   //defines: rtdm_task_t, rtdm_sem_t, ... (also
includes rtdm.h)

#define TASK_PRIO  20 //99 is Highest RT priority, 0 is Lowest

#define us 1000 //1000 ns = 1 us (micro sec)
#define ms 1000000ll //1000000 ns = 1 ms
#define TASK_PERIOD 500*ms //0.5 secs period

#define COUNT 0x80
#define DATA  0x81

rtdm_task_t td_pw;  //RTDM task descriptor
rtdm_sem_t  semA;   //RTDM semaphore descriptor

void writeport (void *arg) {
static unsigned char count=0;
int err;

for (;;) {
err = rtdm_task_wait_period(); //deschedule until next period
if (err<0) {
rtdm_printk("writeportK: rtdm_task_wait_period, error %d\n", err);
break; //avoid kernel corruption when removing module
//trying to execute code of killed thread
}
outb (count, COUNT); //outb takes aprox. 1 Micro sec.
outb (count%4, DATA); //outb takes aprox. 1 Micro sec.
rtdm_printk("writeportK: count = %d\n", count); //check with dmesg
if (++count == 100) count=0;
}
}


int init_module(void) {
int err;

err = rtdm_task_init (&td_pw, "writeportK", writeport, NULL, TASK_PRIO,
TASK_PERIOD);
if (err < 0) rtdm_printk("writeportK: rtdm_task_init, error %d\n", err);
else {
err = rtdm_task_set_period(&td_pw, TASK_PERIOD); //set period
if (err < 0) rtdm_printk("writeportK: rtdm_task_set_period %d\n", err);
else rtdm_printk("writeportK successfully loaded\n");
}
return err;
}

void cleanup_module(void) {
rtdm_task_destroy(&td_pw);
rtdm_printk("writeportK unloaded\n");
}

MODULE_LICENSE("GPL");  //To have access to Xenomai symbols






On 19 March 2015 at 18:29, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/19/2015 06:23 PM, Philippe Gerum wrote:
> > On 03/17/2015 06:19 PM, Helder Daniel wrote:
> >> ok
> >>
> >> On 17 March 2015 at 17:10, Philippe Gerum <rpm@xenomai.org
> >> <mailto:rpm@xenomai.org>> wrote:
> >>
> >>     On 03/17/2015 06:06 PM, Helder Daniel wrote:
> >>     > I am sorry I just found now.
> >>     > It still happens with Mercury (with the configuration described
> in the
> >>     > previous email)
> >>     >
> >>     > When I compiled another app and try to run it I got the same
> error:
> >>     >
> >>     > root@debian:~/09-portAccessSyncTwoAppsC++# ./writeport
> >>     > sysregd:
> create_directory_recursive("/var/run/xenomai/anon/system"):
> >>     > Transport endpoint is not connected
> >>     > sysregd:
> create_directory_recursive("/var/run/xenomai/anon/system"):
> >>     > Transport endpoint is not connected
> >>     > sysregd:
> create_directory_recursive("/var/run/xenomai/anon/system"):
> >>     > Transport endpoint is not connected
> >>     >    3"012.188| WARNING: [main] cannot connect to registry daemon
> >>     >    3"012.188| BUG: [main] initialization failed, EAGAIN
> >>
> >>     Ok. This one is different from the ENOMEM issue, which is
> >>     Cobalt-specific. The problem with mounting the anon/system root is a
> >>     FUSE issue, which still needs a work around it seems.
> >>
> >
> > The ENOMEM issue is now fixed in -next. I'll tackle the C++ parsing
> > problem with libtrank next.
> >
>
> This commit in -next fixes the link stage for the readport/writeport test.
>
>
> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=f537649c1b69a4f7b6d8f22ef344faf3414fe079
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

PS: Version that I am using now

xenomai-3-655dda153fbaba31246963f3011fff194fbecaa8.tar.bz2
<http://git.xenomai.org/xenomai-3.git/snapshot/xenomai-3-655dda153fbaba31246963f3011fff194fbecaa8.tar.bz2>

PS: Version that compiled ok:

xenomai-3-9b8fa963ae6c4751602c00f6be81861b620822af.tar.bz2
<http://git.xenomai.org/xenomai-3.git/snapshot/xenomai-3-9b8fa963ae6c4751602c00f6be81861b620822af.tar.bz2>


On 23 March 2015 at 10:59, Helder Daniel <hdaniel@ualg.pt> wrote:

> Ok,
>
> but now I am compiling a module to write for an I/O port (code below)
> With the previous version of next branch I can compile it without any
> error, insert it check that it is working fine by reading te I/O port from
> an user space app, but with this new version, when compiling the module, I
> get:
>
>  CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
> In file included from include/xenomai/rtdm/driver.h:43:0,
>                  from
> /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
> include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
> cobalt/uapi/corectl.h: No such file or directory
>  #include <cobalt/uapi/corectl.h>
>                                  ^
> compilation terminated.
>
> The makefile is just:
>
> obj-m += writeportK.o
>
> $(eval EXTRA_CFLAGS := $(shell xeno-config --kcflags))
>
> all:
> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>
>
> And the code of the module:
>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <rtdm/driver.h>   //defines: rtdm_task_t, rtdm_sem_t, ... (also
> includes rtdm.h)
>
> #define TASK_PRIO  20 //99 is Highest RT priority, 0 is Lowest
>
> #define us 1000 //1000 ns = 1 us (micro sec)
> #define ms 1000000ll //1000000 ns = 1 ms
> #define TASK_PERIOD 500*ms //0.5 secs period
>
> #define COUNT 0x80
> #define DATA  0x81
>
> rtdm_task_t td_pw;  //RTDM task descriptor
> rtdm_sem_t  semA;   //RTDM semaphore descriptor
>
> void writeport (void *arg) {
> static unsigned char count=0;
> int err;
>
> for (;;) {
> err = rtdm_task_wait_period(); //deschedule until next period
> if (err<0) {
> rtdm_printk("writeportK: rtdm_task_wait_period, error %d\n", err);
> break; //avoid kernel corruption when removing module
> //trying to execute code of killed thread
> }
> outb (count, COUNT); //outb takes aprox. 1 Micro sec.
> outb (count%4, DATA); //outb takes aprox. 1 Micro sec.
> rtdm_printk("writeportK: count = %d\n", count); //check with dmesg
> if (++count == 100) count=0;
> }
> }
>
>
> int init_module(void) {
> int err;
>
> err = rtdm_task_init (&td_pw, "writeportK", writeport, NULL, TASK_PRIO,
> TASK_PERIOD);
> if (err < 0) rtdm_printk("writeportK: rtdm_task_init, error %d\n", err);
> else {
> err = rtdm_task_set_period(&td_pw, TASK_PERIOD); //set period
> if (err < 0) rtdm_printk("writeportK: rtdm_task_set_period %d\n", err);
> else rtdm_printk("writeportK successfully loaded\n");
> }
> return err;
> }
>
> void cleanup_module(void) {
> rtdm_task_destroy(&td_pw);
> rtdm_printk("writeportK unloaded\n");
> }
>
> MODULE_LICENSE("GPL");  //To have access to Xenomai symbols
>
>
>
>
>
>
> On 19 March 2015 at 18:29, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> On 03/19/2015 06:23 PM, Philippe Gerum wrote:
>> > On 03/17/2015 06:19 PM, Helder Daniel wrote:
>> >> ok
>> >>
>> >> On 17 March 2015 at 17:10, Philippe Gerum <rpm@xenomai.org
>> >> <mailto:rpm@xenomai.org>> wrote:
>> >>
>> >>     On 03/17/2015 06:06 PM, Helder Daniel wrote:
>> >>     > I am sorry I just found now.
>> >>     > It still happens with Mercury (with the configuration described
>> in the
>> >>     > previous email)
>> >>     >
>> >>     > When I compiled another app and try to run it I got the same
>> error:
>> >>     >
>> >>     > root@debian:~/09-portAccessSyncTwoAppsC++# ./writeport
>> >>     > sysregd:
>> create_directory_recursive("/var/run/xenomai/anon/system"):
>> >>     > Transport endpoint is not connected
>> >>     > sysregd:
>> create_directory_recursive("/var/run/xenomai/anon/system"):
>> >>     > Transport endpoint is not connected
>> >>     > sysregd:
>> create_directory_recursive("/var/run/xenomai/anon/system"):
>> >>     > Transport endpoint is not connected
>> >>     >    3"012.188| WARNING: [main] cannot connect to registry daemon
>> >>     >    3"012.188| BUG: [main] initialization failed, EAGAIN
>> >>
>> >>     Ok. This one is different from the ENOMEM issue, which is
>> >>     Cobalt-specific. The problem with mounting the anon/system root is
>> a
>> >>     FUSE issue, which still needs a work around it seems.
>> >>
>> >
>> > The ENOMEM issue is now fixed in -next. I'll tackle the C++ parsing
>> > problem with libtrank next.
>> >
>>
>> This commit in -next fixes the link stage for the readport/writeport test.
>>
>>
>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=f537649c1b69a4f7b6d8f22ef344faf3414fe079
>>
>> --
>> Philippe.
>>
>
>
>
> --
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/23/2015 11:59 AM, Helder Daniel wrote:
> Ok,
> 
> but now I am compiling a module to write for an I/O port (code below)
> With the previous version of next branch I can compile it without any
> error, insert it check that it is working fine by reading te I/O port
> from an user space app, but with this new version, when compiling the
> module, I get:
> 
>  CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
> In file included from include/xenomai/rtdm/driver.h:43:0,
>                  from
> /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
> include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
> cobalt/uapi/corectl.h: No such file or directory
>  #include <cobalt/uapi/corectl.h>

I just checked and the module builds fine ou of tree, using the very
same Makefile. Could you check that the kernel you build against is
actually prepared with Xenomai sources?

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

It seems that the Xenomai support was not loaded at boot time:

root@debian:/usr/src# dmesg | grep -i xeno
[    1.780077] [Xenomai] scheduling class idle registered.
[    1.780077] [Xenomai] scheduling class rt registered.
[    1.784077] [Xenomai] init failed, code -19
[   12.612754] *** RTnet for Xenomai v3.0-rc3 ***

I rebooted and now it seems it is loaded:

 dmesg | grep -i xeno
[    1.048963] [Xenomai] scheduling class idle registered.
[    1.048985] [Xenomai] scheduling class rt registered.
[    1.049211] I-pipe: head domain Xenomai registered.
[    1.070494] [Xenomai] Cobalt v3.0-rc3 (Exact Zero)
[    5.453304] *** RTnet for Xenomai v3.0-rc3 ***

But I still get the same compilation error.
I can compile and run a Xenomai user space app.

I am using a Cobalt setup, kernel 3.16, ipipe patch version
3: ipipe-core-3.16-x86-3.patch

root@debian:/usr/src# uname -a
Linux debian 3.16.0-ipipe #1 SMP Fri Mar 6 14:27:41 WET 2015 x86_64
GNU/Linux

root@debian:/usr/xenoami/sbin/version -a
Xenomai/cobalt v3.0-rc3 --
Target: x86_64-unknown-linux-gnu
Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
Build args:  '--with-core=cobalt' '--enable-registry' '--enable-pshared'
'--enable-smp'


On 23 March 2015 at 11:16, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/23/2015 11:59 AM, Helder Daniel wrote:
> > Ok,
> >
> > but now I am compiling a module to write for an I/O port (code below)
> > With the previous version of next branch I can compile it without any
> > error, insert it check that it is working fine by reading te I/O port
> > from an user space app, but with this new version, when compiling the
> > module, I get:
> >
> >  CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
> > In file included from include/xenomai/rtdm/driver.h:43:0,
> >                  from
> > /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
> > include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
> > cobalt/uapi/corectl.h: No such file or directory
> >  #include <cobalt/uapi/corectl.h>
>
> I just checked and the module builds fine ou of tree, using the very
> same Makefile. Could you check that the kernel you build against is
> actually prepared with Xenomai sources?
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

PS: I can run also /usr/xenomai/bin/latency

On 23 March 2015 at 11:47, Helder Daniel <hdaniel@ualg.pt> wrote:

> It seems that the Xenomai support was not loaded at boot time:
>
> root@debian:/usr/src# dmesg | grep -i xeno
> [    1.780077] [Xenomai] scheduling class idle registered.
> [    1.780077] [Xenomai] scheduling class rt registered.
> [    1.784077] [Xenomai] init failed, code -19
> [   12.612754] *** RTnet for Xenomai v3.0-rc3 ***
>
> I rebooted and now it seems it is loaded:
>
>  dmesg | grep -i xeno
> [    1.048963] [Xenomai] scheduling class idle registered.
> [    1.048985] [Xenomai] scheduling class rt registered.
> [    1.049211] I-pipe: head domain Xenomai registered.
> [    1.070494] [Xenomai] Cobalt v3.0-rc3 (Exact Zero)
> [    5.453304] *** RTnet for Xenomai v3.0-rc3 ***
>
> But I still get the same compilation error.
> I can compile and run a Xenomai user space app.
>
> I am using a Cobalt setup, kernel 3.16, ipipe patch version
> 3: ipipe-core-3.16-x86-3.patch
>
> root@debian:/usr/src# uname -a
> Linux debian 3.16.0-ipipe #1 SMP Fri Mar 6 14:27:41 WET 2015 x86_64
> GNU/Linux
>
> root@debian:/usr/xenoami/sbin/version -a
> Xenomai/cobalt v3.0-rc3 --
> Target: x86_64-unknown-linux-gnu
> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
> Build args:  '--with-core=cobalt' '--enable-registry' '--enable-pshared'
> '--enable-smp'
>
>
> On 23 March 2015 at 11:16, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> On 03/23/2015 11:59 AM, Helder Daniel wrote:
>> > Ok,
>> >
>> > but now I am compiling a module to write for an I/O port (code below)
>> > With the previous version of next branch I can compile it without any
>> > error, insert it check that it is working fine by reading te I/O port
>> > from an user space app, but with this new version, when compiling the
>> > module, I get:
>> >
>> >  CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
>> > In file included from include/xenomai/rtdm/driver.h:43:0,
>> >                  from
>> > /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
>> > include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
>> > cobalt/uapi/corectl.h: No such file or directory
>> >  #include <cobalt/uapi/corectl.h>
>>
>> I just checked and the module builds fine ou of tree, using the very
>> same Makefile. Could you check that the kernel you build against is
>> actually prepared with Xenomai sources?
>>
>> --
>> Philippe.
>>
>
>
>
> --
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

But the issue should not be the Xenomai version.

With the older version now I am getting the same compilation error.

I mean the older next branch Xenomai 3 version

On 23 March 2015 at 11:47, Helder Daniel <hdaniel@ualg.pt> wrote:

> PS: I can run also /usr/xenomai/bin/latency
>
> On 23 March 2015 at 11:47, Helder Daniel <hdaniel@ualg.pt> wrote:
>
>> It seems that the Xenomai support was not loaded at boot time:
>>
>> root@debian:/usr/src# dmesg | grep -i xeno
>> [    1.780077] [Xenomai] scheduling class idle registered.
>> [    1.780077] [Xenomai] scheduling class rt registered.
>> [    1.784077] [Xenomai] init failed, code -19
>> [   12.612754] *** RTnet for Xenomai v3.0-rc3 ***
>>
>> I rebooted and now it seems it is loaded:
>>
>>  dmesg | grep -i xeno
>> [    1.048963] [Xenomai] scheduling class idle registered.
>> [    1.048985] [Xenomai] scheduling class rt registered.
>> [    1.049211] I-pipe: head domain Xenomai registered.
>> [    1.070494] [Xenomai] Cobalt v3.0-rc3 (Exact Zero)
>> [    5.453304] *** RTnet for Xenomai v3.0-rc3 ***
>>
>> But I still get the same compilation error.
>> I can compile and run a Xenomai user space app.
>>
>> I am using a Cobalt setup, kernel 3.16, ipipe patch version
>> 3: ipipe-core-3.16-x86-3.patch
>>
>> root@debian:/usr/src# uname -a
>> Linux debian 3.16.0-ipipe #1 SMP Fri Mar 6 14:27:41 WET 2015 x86_64
>> GNU/Linux
>>
>> root@debian:/usr/xenoami/sbin/version -a
>> Xenomai/cobalt v3.0-rc3 --
>> Target: x86_64-unknown-linux-gnu
>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>> Build args:  '--with-core=cobalt' '--enable-registry' '--enable-pshared'
>> '--enable-smp'
>>
>>
>> On 23 March 2015 at 11:16, Philippe Gerum <rpm@xenomai.org> wrote:
>>
>>> On 03/23/2015 11:59 AM, Helder Daniel wrote:
>>> > Ok,
>>> >
>>> > but now I am compiling a module to write for an I/O port (code below)
>>> > With the previous version of next branch I can compile it without any
>>> > error, insert it check that it is working fine by reading te I/O port
>>> > from an user space app, but with this new version, when compiling the
>>> > module, I get:
>>> >
>>> >  CC [M]  /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.o
>>> > In file included from include/xenomai/rtdm/driver.h:43:0,
>>> >                  from
>>> > /mnt/hgfs/apps-3.x/10-portAccessSyncKernel/writeportK.c:8:
>>> > include/xenomai/cobalt/kernel/init.h:24:33: fatal error:
>>> > cobalt/uapi/corectl.h: No such file or directory
>>> >  #include <cobalt/uapi/corectl.h>
>>>
>>> I just checked and the module builds fine ou of tree, using the very
>>> same Makefile. Could you check that the kernel you build against is
>>> actually prepared with Xenomai sources?
>>>
>>> --
>>> Philippe.
>>>
>>
>>
>>
>> --
>> Helder Daniel
>> UALG - FCT
>> DEEI
>>
>> http://w3.ualg.pt/~hdaniel
>>
>
>
>
> --
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/23/2015 12:47 PM, Helder Daniel wrote:
> PS: I can run also /usr/xenomai/bin/latency
> 

Sorry, you lost me. You are trying way too many things in parallel,
reporting apparently inconsistent results.

If you can run latency, then the Cobalt inits certainly went well. Or
maybe you are running a Mercury version of latency, in which case you
might have two Xenomai installations somehow conflicting.

The last time you reported ENODEV when booting Cobalt, you also
mentioned that using the latest patch including this change did fix the
issue:
http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=02416ccdfe926cc1434dc8e0b1fb03693718c45d

At this point, it looks like this is a local installation issue, not a
Xenomai one.

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

On 23 March 2015 at 13:21, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/23/2015 12:47 PM, Helder Daniel wrote:
> > PS: I can run also /usr/xenomai/bin/latency
> >
>
> Sorry, you lost me. You are trying way too many things in parallel,
> reporting apparently inconsistent results.
>

I am sorry.
I am porting several demos that I developed in 2.5 to version 3.
Kernel space and userspace. And yes I am trying too many things at once.
I tried to filter the issues when asking for your help but it seems I don't.

If you can run latency, then the Cobalt inits certainly went well.


Yes. After reboot: dmesg | grep -i xeno reported that Cobalt inits well.


> Or
> maybe you are running a Mercury version of latency, in which case you
> might have two Xenomai installations somehow conflicting.
>

I thought also that this might be an installation issue so I deleted
/usr/xenoami before reinstalling Xenomay (Cobalt) again.


> The last time you reported ENODEV when booting Cobalt, you also
> mentioned that using the latest patch including this change did fix the
> issue:
>
> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=02416ccdfe926cc1434dc8e0b1fb03693718c45d


Yes. But now I noticed that sometimes Cobalt does not initialize returning
ENODEV.


>
> At this point, it looks like this is a local installation issue, not a
> Xenomai one.


It might. I am gonna reinstall everything from scratch (kernel too), before
I get back to you again.

Thanks

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

Hi,

I installed ipipe patched linux 3.16.7 and Xenomai 3.0-rc4 from the scratch
and all the compiling errors that I was experiencing were gone.

So It should have been a local installation issue as you pointed out.
Probably due to many reinstalls of successive Xenomai new versions, without
proper clean up of the oldest.
I am just cleaning the oldest one removing folder /usr/xenomai.
May be there is a better way?

Sorry to mess up things.

thanks



On 23 March 2015 at 13:55, Helder Daniel <hdaniel@ualg.pt> wrote:

> On 23 March 2015 at 13:21, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> On 03/23/2015 12:47 PM, Helder Daniel wrote:
>> > PS: I can run also /usr/xenomai/bin/latency
>> >
>>
>> Sorry, you lost me. You are trying way too many things in parallel,
>> reporting apparently inconsistent results.
>>
>
> I am sorry.
> I am porting several demos that I developed in 2.5 to version 3.
> Kernel space and userspace. And yes I am trying too many things at once.
> I tried to filter the issues when asking for your help but it seems I
> don't.
>
> If you can run latency, then the Cobalt inits certainly went well.
>
>
> Yes. After reboot: dmesg | grep -i xeno reported that Cobalt inits well.
>
>
>> Or
>> maybe you are running a Mercury version of latency, in which case you
>> might have two Xenomai installations somehow conflicting.
>>
>
> I thought also that this might be an installation issue so I deleted
> /usr/xenoami before reinstalling Xenomay (Cobalt) again.
>
>
>> The last time you reported ENODEV when booting Cobalt, you also
>> mentioned that using the latest patch including this change did fix the
>> issue:
>>
>> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=02416ccdfe926cc1434dc8e0b1fb03693718c45d
>
>
> Yes. But now I noticed that sometimes Cobalt does not initialize returning
> ENODEV.
>
>
>>
>> At this point, it looks like this is a local installation issue, not a
>> Xenomai one.
>
>
> It might. I am gonna reinstall everything from scratch (kernel too),
> before I get back to you again.
>
> Thanks
>
>
>
>


-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Philippe Gerum]

On 03/30/2015 06:51 PM, Helder Daniel wrote:
> Hi,
> 
> I installed ipipe patched linux 3.16.7 and Xenomai 3.0-rc4 from the
> scratch and all the compiling errors that I was experiencing were gone.
> 
> So It should have been a local installation issue as you pointed out.
> Probably due to many reinstalls of successive Xenomai new versions,
> without proper clean up of the oldest.
> I am just cleaning the oldest one removing folder /usr/xenomai.
> May be there is a better way?
> 

$ make uninstall

-- 
Philippe.

Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel]

right ... thanks :)


On 31 March 2015 at 08:27, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/30/2015 06:51 PM, Helder Daniel wrote:
> > Hi,
> >
> > I installed ipipe patched linux 3.16.7 and Xenomai 3.0-rc4 from the
> > scratch and all the compiling errors that I was experiencing were gone.
> >
> > So It should have been a local installation issue as you pointed out.
> > Probably due to many reinstalls of successive Xenomai new versions,
> > without proper clean up of the oldest.
> > I am just cleaning the oldest one removing folder /usr/xenomai.
> > May be there is a better way?
> >
>
> $ make uninstall
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel