[Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

Hallo,

I have problems to bind named semaphores from an external process using
the alchemy API.  Below a detailed description. Does anyone have a suggestion

what could be wrong or what I could do to solve the problem ?
Kind regards,

Frederik

In attachment an example to reproduce my problem (makefile, stest.c).
If you run 'sudo ./stest 1', a named semaphore is created and a task is started
that binds it and perform a p operation. The main task is waiting on CTRL+C,
and then ask the numer of waiters and performs v operations.
If you run 'sudo ./stest 0', the named semaphore is not created, only a task is
started that binds it and perform a p operation.

I start first 'sudo ./stest 1'. The process binds the semaphore and blocks on rt_sem_p.
The content of /var/run/xenomai is :

xenomai/
xenomai/root
xenomai/root/anon@1262
xenomai/root/anon@1262/1262
xenomai/root/anon@1262/system

Now I execute 'sudo ./stest 0' in another shell.
This process blocks on rt_sem_bind, so the semaphore is not found 

The content of /var/run/xenomai is now :
xenomai/
xenomai/root
xenomai/root/anon@1277
xenomai/root/anon@1277/1277
xenomai/root/anon@1277/system
xenomai/root/anon@1262
xenomai/root/anon@1262/1262
xenomai/root/anon@1262/system

If I press CTRL-C on the first process, I get 

stest.c:146: nwaiters = 1
stest.c:147: count = 0
stest.c:152: calling rt_sem_v 1...
stest.c:60: rt_sem_p passed
stest.c:161: rt_sem_v called
stest.c:184: nwaiters = 0
stest.c:185: count = 0


So there is only 1 waiter (because the 2nd process didn't succeed the bind).

I tried the example also on xenomai 2.4.10 and there it's working.

I'm using linux-3.18.12, xenomai-3.0-rc5 (from tarball) and ipipe-core-3.18.12-x86-1.patch
I configured CONFIG_FUSE_FS=m in the kernel (see configuration in attachment), module fuse is loaded.

My linux distribution is debian - jessie. The fuse packages are installed :

ii  fuse             2.9.3-15+b1  amd64    Filesystem in Userspace
ii  gvfs-fuse        1.22.2-1     amd64    userspace virtual filesystem - fuse server
ii  libfuse-dev      2.9.3-15+b1  amd64    Filesystem in Userspace (development)
ii  libfuse2:amd64   2.9.3-15+b1  amd64    Filesystem in Userspace (library)

To build xenomai debian packages, I added following configure options to debian/rules :
--with-core=cobalt --enable-smp --enable-pshared --enable-registry
and then executed `debuild -uc -us`

The output of `xeno-config --info` :

Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5
root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11
ro quiet console=tty0 console=ttyS0,115200n8
I-pipe release #1 detected
Cobalt core 3.0-rc5 detected
Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
Build args: --prefix=/usr --includedir=/usr/include/xenomai
--mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite
--with-core=cobalt --enable-smp --enable-pshared --enable-registry
--build x86_64-linux-gnu build_alias=x86_64-linux-gnu

The shared libraries in use :
ldd ./stest
linux-vdso.so.1 (0x00007fff422e5000)
libalchemy.so.0 => /usr/lib/libalchemy.so.0 (0x00007f0da8bf6000)
libcopperplate.so.0 => /usr/lib/libcopperplate.so.0 (0x00007f0da89df000)
libcobalt.so.2 => /usr/lib/libcobalt.so.2 (0x00007f0da87be000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0da85a1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0da8399000)
libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f0da815a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0da7db1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0da8e25000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0da7bad000)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-3.18.12-x86-64-xeno-3.0.rc5
Type: application/octet-stream
Size: 126458 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150713/4f971614/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 794 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150713/4f971614/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stest.c
Type: text/x-csrc
Size: 4041 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150713/4f971614/attachment.c>

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/13/2015 03:37 PM, Frederik Bayart wrote:
> Hallo,
> 
> I have problems to bind named semaphores from an external process using
> the alchemy API.  Below a detailed description. Does anyone have a suggestion
> 
> what could be wrong or what I could do to solve the problem ?
> Kind regards,
> 
> Frederik
> 
> In attachment an example to reproduce my problem (makefile, stest.c).
> If you run 'sudo ./stest 1', a named semaphore is created and a task is started
> that binds it and perform a p operation. The main task is waiting on CTRL+C,
> and then ask the numer of waiters and performs v operations.
> If you run 'sudo ./stest 0', the named semaphore is not created, only a task is
> started that binds it and perform a p operation.
> 
> I start first 'sudo ./stest 1'. The process binds the semaphore and blocks on rt_sem_p.
> The content of /var/run/xenomai is :
> 

[snip]

The key issue is that multiple programs forming a single application
must belong to the same Xenomai session, for sharing data/objects. The
notion of "session" was introduced by Xenomai 3.

So, all you need to do, is to tell the application bootstrap code about
the session you want to create between several programs, e.g.:

# ./stest --session=foo 1
# ./stest --session=foo 0

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

> On Tuesday, 14 July 2015, 11:53, Philippe Gerum <rpm@xenomai.org> wrote:
>
>
>On 07/13/2015 03:37 PM, Frederik Bayart wrote:
>
>> Hallo,
>>
>> I have problems to bind named semaphores from an external process using
>> the alchemy API.  Below a detailed description. Does anyone have a suggestion
>>
>> what could be wrong or what I could do to solve the problem ?
>> Kind regards,
>>
>> Frederik
>>
>> In attachment an example to reproduce my problem (makefile, stest.c).
>> If you run 'sudo ./stest 1', a named semaphore is created and a task is started
>> that binds it and perform a p operation. The main task is waiting on CTRL+C,
>> and then ask the numer of waiters and performs v operations.
>> If you run 'sudo ./stest 0', the named semaphore is not created, only a task is
>> started that binds it and perform a p operation.
>>
>> I start first 'sudo ./stest 1'. The process binds the semaphore and blocks on rt_sem_p.
>> The content of /var/run/xenomai is :
>
>>
>
>[snip]
>
>The key issue is that multiple programs forming a single application
>must belong to the same Xenomai session, for sharing data/objects. The
>notion of "session" was introduced by Xenomai 3.
>
>So, all you need to do, is to tell the application bootstrap code about
>the session you want to create between several programs, e.g.:
>
># ./stest --session=foo 1
># ./stest --session=foo 0
>
>-- 
>Philippe.

This works. I still notice 2 issues :

1) If you execute reversely

./stest --session=foo 0
./stest --session=foo 1

The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.

So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :

[ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
[ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]


2)

The fuse filesystem is not unmounted. This is because in xenomai-3.0-rc5/lib/copperplate/regd/regd.c the fullpath is hardcoded to fusermount and umount

sh: 1: /usr/bin/fusermount: not found
sysregd: create_directory_recursive("/var/run/xenomai/root/stest/system"): Transport endpoint is not connected
sh: 1: /usr/bin/fusermount: not found
sysregd: create_directory_recursive("/var/run/xenomai/root/stest/system"): Transport endpoint is not connected
sh: 1: /usr/bin/fusermount: not found
sysregd: create_directory_recursive("/var/run/xenomai/root/stest/system"): Transport endpoint is not connected
0"602.802| WARNING: [main] cannot connect to registry daemon
0"602.875| WARNING: [main] setup call copperplate failed
0"602.929| BUG in xenomai_init(): [main] initialization failed, EAGAIN

In the code is written :

/usr/bin/fusermount
/usr/bin/umount

However, on debian jessie, these binaries are in /bin, not in /usr/bin.
It's hardcoded, so if I think this is not a configure problem.

I could fixed it, with the diff below. It's not clear to me why access of umount is tested and not from fusermount.


Frederik


--- regd.c.old    2015-07-14 15:58:09.748049358 +0200
+++ regd.c.new    2015-07-15 14:41:52.798401291 +0200
@@ -22,6 +22,7 @@
#include <sys/select.h>
#include <sys/timerfd.h>
#include <sys/un.h>
+#include <linux/limits.h>
#include <signal.h>
#include <stdio.h>
#include <limits.h>
@@ -65,6 +66,8 @@
struct pvholder next;
};

+static char *umount_fullpath = NULL;
+
static DEFINE_PRIVATE_LIST(client_list);

static void usage(void)
@@ -76,6 +79,36 @@
fprintf(stderr, "               [--linger]       disable timed exit on idleness\n");
}

+static char *afullpath(const char *cmd)
+{
+    FILE *fp;
+    char *which_cmd;
+    char path[PATH_MAX];
+    char *fullpath;
+    int len;
+
+    if (asprintf(&which_cmd, "which %s", cmd) == -1)
+        return NULL;
+
+    fp = popen(which_cmd, "r");
+    free(which_cmd);
+    if (fp == NULL)
+        return NULL;
+
+    if (fgets(path, sizeof(path), fp) == NULL) {
+        pclose(fp);
+        return NULL;
+    }
+
+    pclose(fp);
+    len = strlen(path) - 1;
+    if (path[len] == '\n')
+        path[len--] = '\0';
+    fullpath = malloc(len+2);
+    strcpy(fullpath, path);
+    return fullpath;
+}
+
static const struct option options[] = {
{
#define help_opt    0
@@ -279,7 +312,7 @@
if (flags >= 0)
fcntl(2, F_SETFD, flags | FD_CLOEXEC);

-    ret = asprintf(&cmd, "/usr/bin/fusermount -uzq %s", path);
+    ret = asprintf(&cmd, "fusermount -uzq %s", path);
if (ret < 0)
return;

@@ -288,10 +321,10 @@
if (ret != -1 && WIFEXITED(ret) && WEXITSTATUS(ret) == 0)
return;

-    if (access("/usr/bin/umount", X_OK))
+    if (access(umount_fullpath, X_OK))
return;

-    ret = asprintf(&cmd, "/usr/bin/umount -l %s", path);
+    ret = asprintf(&cmd, "%s -l %s", umount_fullpath, path);
if (ret < 0)
return;

@@ -529,6 +562,10 @@
if (rootdir == NULL)
error(1, EINVAL, "--root must be given");

+    umount_fullpath = afullpath("umount");
+    if (umount_fullpath == NULL)
+        error(1, ENOENT, "umount not found in path");
+
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
sigaction(SIGCHLD, &sa, NULL);
@@ -544,6 +581,7 @@
bind_socket();
create_system_fs(argv[0], rootdir, flags);
handle_requests();
+    free(umount_fullpath);

return 0;

}

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/15/2015 02:45 PM, Frederik Bayart wrote:
> This works. I still notice 2 issues :
> 
> 1) If you execute reversely
> 
> ./stest --session=foo 0
> ./stest --session=foo 1
> 
> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
> 
> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
> 
> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>

Looking at the copperplate code, yep, this definitely can't work. Ok,
queued.

> 
> 2)
> 
> The fuse filesystem is not unmounted. This is because in xenomai-3.0-rc5/lib/copperplate/regd/regd.c the fullpath is hardcoded to fusermount and umount
> 
> I could fixed it, with the diff below. It's not clear to me why access of umount is tested and not from fusermount.
> 

Piping the "which" output seems seriously overkill. Besides, we don't
want to rely on the environment to find those paths, we are running with
supervisor privileges (i.e. we don't want to run what the user tells us
what "umount" should be, but rather what the distro actually says
"umount" is).

Per LSB 3.0, /bin/umount would be the place to find this, so basically,
testing a couple of reasonable locations should be enough.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>> ./stest --session=foo 1
>>
>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>
>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>
>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>
>
>Looking at the copperplate code, yep, this definitely can't work. Ok,
>queued.

I noticed also :

 ./stest --session=foo 1
 ./stest --session=foo 0

Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised. At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>
>>
>> 2)
>>
>> The fuse filesystem is not unmounted. This is because in xenomai-3.0-rc5/lib/copperplate/regd/regd.c the fullpath is hardcoded to fusermount and umount
>>
>> I could fixed it, with the diff below. It's not clear to me why access of umount is tested and not from fusermount.
>>
>
>Piping the "which" output seems seriously overkill. Besides, we don't
>want to rely on the environment to find those paths, we are running with
>supervisor privileges (i.e. we don't want to run what the user tells us
>what "umount" should be, but rather what the distro actually says
>"umount" is).
>
>Per LSB 3.0, /bin/umount would be the place to find this, so basically,
>testing a couple of reasonable locations should be enough.
>
>
>-- 
>Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>> ./stest --session=foo 1
>>>
>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>
>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>
>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>
>>
>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>> queued.
> 
> I noticed also :
> 
>  ./stest --session=foo 1
>  ./stest --session=foo 0
> 
> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.


Spurious wake up in the Cobalt kernel when aborting a sem wait operation
due to a signal/unblock event, that is the reason why I could not see
this from a Mercury setup. This is fixed in the -next branch.

> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.

I don't observe this one. Assuming you enabled the registry, what does
/var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
sema4 value?

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>
>
>On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>> ./stest --session=foo 1
>>>>
>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>
>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>
>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>
>>>
>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>> queued.
>>
>> I noticed also :
>>
>>  ./stest --session=foo 1
>>  ./stest --session=foo 0
>>
>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>
>
>Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>due to a signal/unblock event, that is the reason why I could not see
>this from a Mercury setup. This is fixed in the -next branch.
>
>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>
>I don't observe this one. Assuming you enabled the registry, what does
>/var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>sema4 value?
>

When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?

The output of 'xeno-config --info' is :

Xenomai version: Xenomai/cobalt v3.0-rc5 -- 
Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
I-pipe release #1 detected
Cobalt core 3.0-rc5 detected
Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu

I have only this in the registery :

find /var/run/xenomai

/var/run/xenomai
/var/run/xenomai/root
/var/run/xenomai/root/foo
/var/run/xenomai/root/foo/6210
/var/run/xenomai/root/foo/6203
/var/run/xenomai/root/foo/system


In attachment my latest version of stest.c to be sure, there are only small modifications.

Below the output of the first process

sudo ./stest --session=foo 1
stest.c:82: __XENO_COMPAT__ not defined, create = 1
stest.c:121: enter CTRL+C to continue...
stest.c:43: binding sem semtestsem...
stest.c:51: calling rt_sem_p...
========= Now CTRL+C on the second (other) process ======================
stest.c:60: rt_sem_p passed
========= Now CTRL+C on this (first) process to interrupt the wait loop =========
stest.c:32: signal(2)
stest.c:146: nwaiters = 1
stest.c:147: count = 0
stest.c:152: calling rt_sem_v 1...
stest.c:161: rt_sem_v called
stest.c:186: nwaiters = 0
stest.c:187: count = 0

>-- 
>Philippe.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stest.c
Type: text/x-csrc
Size: 4401 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150729/df21dd27/attachment.c>

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>
>>
>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>> ./stest --session=foo 1
>>>>>
>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>
>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>
>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>
>>>>
>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>> queued.
>>>
>>> I noticed also :
>>>
>>>  ./stest --session=foo 1
>>>  ./stest --session=foo 0
>>>
>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>
>>
>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>> due to a signal/unblock event, that is the reason why I could not see
>> this from a Mercury setup. This is fixed in the -next branch.
>>
>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>
>> I don't observe this one. Assuming you enabled the registry, what does
>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>> sema4 value?
>>
> 
> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
> 
> The output of 'xeno-config --info' is :
> 
> Xenomai version: Xenomai/cobalt v3.0-rc5 -- 
> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
> I-pipe release #1 detected
> Cobalt core 3.0-rc5 detected

You should be running -rc6.

> Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
> 
> I have only this in the registery :
> 
> find /var/run/xenomai
> 
> /var/run/xenomai
> /var/run/xenomai/root
> /var/run/xenomai/root/foo
> /var/run/xenomai/root/foo/6210
> /var/run/xenomai/root/foo/6203
> /var/run/xenomai/root/foo/system
> 
> 

FUSE services do not seem to be enabled, those directories are the mount
points created by sysregd, over which fuse-managed fs should be mounted.

Are you sure those directories are not left overs from a previous run,
and that you are actually running an executable built over the
configuration settings above?

This would confirm it:

$ <your-app-executable> --dump-config|grep REGISTRY

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 01:48 PM, Frederik Bayart wrote:

> In attachment my latest version of stest.c to be sure, there are only small modifications.
>

If __XENO_COMPAT__ is enabled, that should mean that you built your
application with --[skin=]native, which automatically enables backward
compat mode from {lib, include}/trank, to the new alchemy API.

In this case, you don't need to test this symbol for picking the proper
include files, these are available from include/trank/native, which
xeno-config points you at.

Obsolete definitions like T_FPU will be found in those compat headers.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>
>>
>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>> ./stest --session=foo 1
>>>>>
>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>
>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>
>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>
>>>>
>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>> queued.
>>>
>>> I noticed also :
>>>
>>>  ./stest --session=foo 1
>>>  ./stest --session=foo 0
>>>
>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>
>>
>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>> due to a signal/unblock event, that is the reason why I could not see
>> this from a Mercury setup. This is fixed in the -next branch.
>>
>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>
>> I don't observe this one. Assuming you enabled the registry, what does
>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>> sema4 value?
>>
> 
> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
> 
> The output of 'xeno-config --info' is :
> 
> Xenomai version: Xenomai/cobalt v3.0-rc5 -- 
> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
> I-pipe release #1 detected
> Cobalt core 3.0-rc5 detected
> Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
> 
> I have only this in the registery :
> 
> find /var/run/xenomai
> 
> /var/run/xenomai
> /var/run/xenomai/root
> /var/run/xenomai/root/foo
> /var/run/xenomai/root/foo/6210
> /var/run/xenomai/root/foo/6203
> /var/run/xenomai/root/foo/system
> 
> 
> In attachment my latest version of stest.c to be sure, there are only small modifications.
> 
> Below the output of the first process
> 
> sudo ./stest --session=foo 1
> stest.c:82: __XENO_COMPAT__ not defined, create = 1
> stest.c:121: enter CTRL+C to continue...
> stest.c:43: binding sem semtestsem...
> stest.c:51: calling rt_sem_p...
> ========= Now CTRL+C on the second (other) process ======================
> stest.c:60: rt_sem_p passed

You must mean interrupting the one enabling create mode, i.e.
--session=foo 1. ^C on the other one will terminate it immediately since
it does not trap this signal, leaving the first one hanging on
rt_sem_p() as expected (with the latest fix applied).

> ========= Now CTRL+C on this (first) process to interrupt the wait loop =========
> stest.c:32: signal(2)
> stest.c:146: nwaiters = 1
> stest.c:147: count = 0
> stest.c:152: calling rt_sem_v 1...
> stest.c:161: rt_sem_v called
> stest.c:186: nwaiters = 0
> stest.c:187: count = 0
> 

Looking at your code, I fail to see any issue with this trace output.
What output would you expect instead?

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 02:48 PM, Philippe Gerum wrote:
> On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>>
>>>
>>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>>> ./stest --session=foo 1
>>>>>>
>>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>>
>>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>>
>>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>>
>>>>>
>>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>>> queued.
>>>>
>>>> I noticed also :
>>>>
>>>>  ./stest --session=foo 1
>>>>  ./stest --session=foo 0
>>>>
>>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>>
>>>
>>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>>> due to a signal/unblock event, that is the reason why I could not see
>>> this from a Mercury setup. This is fixed in the -next branch.
>>>
>>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>>
>>> I don't observe this one. Assuming you enabled the registry, what does
>>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>>> sema4 value?
>>>
>>
>> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
>>
>> The output of 'xeno-config --info' is :
>>
>> Xenomai version: Xenomai/cobalt v3.0-rc5 -- 
>> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>> I-pipe release #1 detected
>> Cobalt core 3.0-rc5 detected
>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
>> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>>
>> I have only this in the registery :
>>
>> find /var/run/xenomai
>>
>> /var/run/xenomai
>> /var/run/xenomai/root
>> /var/run/xenomai/root/foo
>> /var/run/xenomai/root/foo/6210
>> /var/run/xenomai/root/foo/6203
>> /var/run/xenomai/root/foo/system
>>
>>
>> In attachment my latest version of stest.c to be sure, there are only small modifications.
>>
>> Below the output of the first process
>>
>> sudo ./stest --session=foo 1
>> stest.c:82: __XENO_COMPAT__ not defined, create = 1
>> stest.c:121: enter CTRL+C to continue...
>> stest.c:43: binding sem semtestsem...
>> stest.c:51: calling rt_sem_p...
>> ========= Now CTRL+C on the second (other) process ======================
>> stest.c:60: rt_sem_p passed
> 
> You must mean interrupting the one enabling create mode, i.e.
> --session=foo 1. ^C on the other one will terminate it immediately since
> it does not trap this signal, leaving the first one hanging on
> rt_sem_p() as expected (with the latest fix applied).
> 
>> ========= Now CTRL+C on this (first) process to interrupt the wait loop =========
>> stest.c:32: signal(2)
>> stest.c:146: nwaiters = 1
>> stest.c:147: count = 0
>> stest.c:152: calling rt_sem_v 1...
>> stest.c:161: rt_sem_v called
>> stest.c:186: nwaiters = 0
>> stest.c:187: count = 0
>>
> 
> Looking at your code, I fail to see any issue with this trace output.
> What output would you expect instead?
> 

In absence of any particular signal disposition (e.g. blocking), SIGINT
can ne sent to the main() thread of your process, which then wakes up
while the one running rt_input() is still pending on rt_sem_p(). Hence
the non-zero waiter count when the main() thread inspects the sema4 data.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>
>On Wednesday, 29 July 2015, 14:48, Philippe Gerum <rpm@xenomai.org> wrote:
>On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>>
>>>
>>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>>> ./stest --session=foo 1
>>>>>>
>>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>>
>>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>>
>>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>>
>>>>>
>>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>>> queued.
>>>>
>>>> I noticed also :
>>>>
>>>>  ./stest --session=foo 1
>>>>  ./stest --session=foo 0
>>>>
>>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>>
>>>
>>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>>> due to a signal/unblock event, that is the reason why I could not see
>>> this from a Mercury setup. This is fixed in the -next branch.
>>>
>>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>>
>>> I don't observe this one. Assuming you enabled the registry, what does
>>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>>> sema4 value?
>>>
>>
>> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
>>
>> The output of 'xeno-config --info' is :
>>
>> Xenomai version: Xenomai/cobalt v3.0-rc5 --
>> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>> I-pipe release #1 detected
>> Cobalt core 3.0-rc5 detected
>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>>
>> I have only this in the registery :
>>
>> find /var/run/xenomai
>>
>> /var/run/xenomai
>> /var/run/xenomai/root
>> /var/run/xenomai/root/foo
>> /var/run/xenomai/root/foo/6210
>> /var/run/xenomai/root/foo/6203
>> /var/run/xenomai/root/foo/system
>>
>>
>> In attachment my latest version of stest.c to be sure, there are only small modifications.
>>
>> Below the output of the first process
>>
>> sudo ./stest --session=foo 1
>> stest.c:82: __XENO_COMPAT__ not defined, create = 1
>> stest.c:121: enter CTRL+C to continue...
>> stest.c:43: binding sem semtestsem...
>> stest.c:51: calling rt_sem_p...
>> ========= Now CTRL+C on the second (other) process ======================
>> stest.c:60: rt_sem_p passed
>
>You must mean interrupting the one enabling create mode, i.e.
>--session=foo 1. ^C on the other one will terminate it immediately since
>it does not trap this signal, leaving the first one hanging on
>rt_sem_p() as expected (with the latest fix applied).
>
>> ========= Now CTRL+C on this (first) process to interrupt the wait loop =========
>> stest.c:32: signal(2)
>> stest.c:146: nwaiters = 1
>> stest.c:147: count = 0
>> stest.c:152: calling rt_sem_v 1...
>> stest.c:161: rt_sem_v called
>> stest.c:186: nwaiters = 0
>> stest.c:187: count = 0
>>
>
>Looking at your code, I fail to see any issue with this trace output.
>What output would you expect instead?

I switched to rc6 (kernel and libraries)

Concerning the registry : 

The fuse module is loaded :
$ lsmod | grep fuse
fuse                   87410  7 

$ sudo ./stest  --dump-config|grep REGISTRY
based on Xenomai/cobalt v3.0-rc6 -- 
CONFIG_XENO_REGISTRY=1
CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"

Is this what I'm supposed to see ?

Before start of the processes :

$ find /var/run/xenomai/
/var/run/xenomai/
/var/run/xenomai/root

After start of processes

$ find /var/run/xenomai/
/var/run/xenomai/
/var/run/xenomai/root
/var/run/xenomai/root/foo
/var/run/xenomai/root/foo/4910
/var/run/xenomai/root/foo/4899
/var/run/xenomai/root/foo/system

$ mount | grep xenomai
sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
stest on /run/xenomai/root/foo/4899 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
stest on /run/xenomai/root/foo/4910 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)

So I haven't any idea why I don't see more subdirectories.

Now concerning the semaphore :

$cat /proc/xenomai/sched/threads | grep rt
3  4899   rt     cobalt      0   -             X          main
3  4902   rt     cobalt      0   -             X          sysregd
3  4904   rt     cobalt      0   -             X          sysregd
3  4906   rt     cobalt      0   -             X          stest
3  4907   rt     cobalt    256   -             W          remote-agent
3  4908   rt     cobalt     40   -             W          4899test
0  4910   rt     cobalt      0   -             X          main
0  4912   rt     cobalt      0   -             X          stest
0  4913   rt     cobalt    256   -             W          remote-agent
0  4914   rt     cobalt     40   -             W          4910test


Now I enter CTRL+C on the second process (the non-creating process). The SIGINT signal is not catched in this process. The second process is ended.

$cat /proc/xenomai/sched/threads | grep rt
3  4899   rt     cobalt      0   -             X          main
3  4902   rt     cobalt      0   -             X          sysregd
3  4904   rt     cobalt      0   -             X          sysregd
3  4906   rt     cobalt      0   -             X          stest
3  4907   rt     cobalt    256   -             W          remote-agent


The rt_sem_p call in the first process also returns with return value 0.
This has as consequence that the task 4899test of the first process is also ended.

So : 

1) Is it OK that if 2 tasks are pending on a shared semophore and 1 of the tasks finishes because of uncatched SIGINT, the other task falls through the semaphore ?

2) If OK, the return value is 0, so the task can't detect whether the semaphore is released because of interrupt of other task or because of rt_sem_v.

Now there are no tasks pending anymore on the semaphore, so I would expect nwaiters = 0

However : CTRL+C on the first semaphore-creating process, the SIGINT signal is catched for this process and a flag is set to end the wait loop.

After the wait loop is ended,  rt_sem_inquire is called and returns :

stest.c:149: nwaiters = 1
stest.c:150: count = 0

I would expect that nwaiters is 0 here.

Then rt_sem_v is called then and only after that nwaiters is 0.


After both processes are finished, the registry is clean and there are no mounts anymore :

$ find /var/run/xenomai/
/var/run/xenomai/
/var/run/xenomai/root

$ mount | grep xenomai

Frederik

>
>
>-- 
>Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 05:14 PM, Frederik Bayart wrote:
>>
>> On Wednesday, 29 July 2015, 14:48, Philippe Gerum <rpm@xenomai.org> wrote:
>> On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>>>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>>>
>>>>
>>>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>>>> ./stest --session=foo 1
>>>>>>>
>>>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>>>
>>>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>>>
>>>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>>>
>>>>>>
>>>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>>>> queued.
>>>>>
>>>>> I noticed also :
>>>>>
>>>>>  ./stest --session=foo 1
>>>>>  ./stest --session=foo 0
>>>>>
>>>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>>>
>>>>
>>>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>>>> due to a signal/unblock event, that is the reason why I could not see
>>>> this from a Mercury setup. This is fixed in the -next branch.
>>>>
>>>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>>>
>>>> I don't observe this one. Assuming you enabled the registry, what does
>>>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>>>> sema4 value?
>>>>
>>>
>>> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
>>>
>>> The output of 'xeno-config --info' is :
>>>
>>> Xenomai version: Xenomai/cobalt v3.0-rc5 --
>>> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>>> I-pipe release #1 detected
>>> Cobalt core 3.0-rc5 detected
>>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>>> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>>>
>>> I have only this in the registery :
>>>
>>> find /var/run/xenomai
>>>
>>> /var/run/xenomai
>>> /var/run/xenomai/root
>>> /var/run/xenomai/root/foo
>>> /var/run/xenomai/root/foo/6210
>>> /var/run/xenomai/root/foo/6203
>>> /var/run/xenomai/root/foo/system
>>>
>>>
>>> In attachment my latest version of stest.c to be sure, there are only small modifications.
>>>
>>> Below the output of the first process
>>>
>>> sudo ./stest --session=foo 1
>>> stest.c:82: __XENO_COMPAT__ not defined, create = 1
>>> stest.c:121: enter CTRL+C to continue...
>>> stest.c:43: binding sem semtestsem...
>>> stest.c:51: calling rt_sem_p...
>>> ========= Now CTRL+C on the second (other) process ======================
>>> stest.c:60: rt_sem_p passed
>>
>> You must mean interrupting the one enabling create mode, i.e.
>> --session=foo 1. ^C on the other one will terminate it immediately since
>> it does not trap this signal, leaving the first one hanging on
>> rt_sem_p() as expected (with the latest fix applied).
>>
>>> ========= Now CTRL+C on this (first) process to interrupt the wait loop =========
>>> stest.c:32: signal(2)
>>> stest.c:146: nwaiters = 1
>>> stest.c:147: count = 0
>>> stest.c:152: calling rt_sem_v 1...
>>> stest.c:161: rt_sem_v called
>>> stest.c:186: nwaiters = 0
>>> stest.c:187: count = 0
>>>
>>
>> Looking at your code, I fail to see any issue with this trace output.
>> What output would you expect instead?
> 
> I switched to rc6 (kernel and libraries)
> 
> Concerning the registry : 
> 
> The fuse module is loaded :
> $ lsmod | grep fuse
> fuse                   87410  7 
> 
> $ sudo ./stest  --dump-config|grep REGISTRY
> based on Xenomai/cobalt v3.0-rc6 -- 
> CONFIG_XENO_REGISTRY=1
> CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
> 
> Is this what I'm supposed to see ?
> 
> Before start of the processes :
> 
> $ find /var/run/xenomai/
> /var/run/xenomai/
> /var/run/xenomai/root
> 
> After start of processes
> 
> $ find /var/run/xenomai/
> /var/run/xenomai/
> /var/run/xenomai/root
> /var/run/xenomai/root/foo
> /var/run/xenomai/root/foo/4910
> /var/run/xenomai/root/foo/4899
> /var/run/xenomai/root/foo/system
> 
> $ mount | grep xenomai
> sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
> stest on /run/xenomai/root/foo/4899 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
> stest on /run/xenomai/root/foo/4910 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
> 
> So I haven't any idea why I don't see more subdirectories.
> 
> Now concerning the semaphore :
> 
> $cat /proc/xenomai/sched/threads | grep rt
> 3  4899   rt     cobalt      0   -             X          main
> 3  4902   rt     cobalt      0   -             X          sysregd
> 3  4904   rt     cobalt      0   -             X          sysregd
> 3  4906   rt     cobalt      0   -             X          stest
> 3  4907   rt     cobalt    256   -             W          remote-agent
> 3  4908   rt     cobalt     40   -             W          4899test
> 0  4910   rt     cobalt      0   -             X          main
> 0  4912   rt     cobalt      0   -             X          stest
> 0  4913   rt     cobalt    256   -             W          remote-agent
> 0  4914   rt     cobalt     40   -             W          4910test
> 
> 
> Now I enter CTRL+C on the second process (the non-creating process). The SIGINT signal is not catched in this process. The second process is ended.
> 
> $cat /proc/xenomai/sched/threads | grep rt
> 3  4899   rt     cobalt      0   -             X          main
> 3  4902   rt     cobalt      0   -             X          sysregd
> 3  4904   rt     cobalt      0   -             X          sysregd
> 3  4906   rt     cobalt      0   -             X          stest
> 3  4907   rt     cobalt    256   -             W          remote-agent
> 
> 
> The rt_sem_p call in the first process also returns with return value 0.
> This has as consequence that the task 4899test of the first process is also ended.

Please merge the commit on top of -rc6 I mentioned this morning, which
fixes the spurious wake up:

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

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/29/2015 08:27 PM, Philippe Gerum wrote:
> On 07/29/2015 05:14 PM, Frederik Bayart wrote:
>>>
>>> On Wednesday, 29 July 2015, 14:48, Philippe Gerum <rpm@xenomai.org> wrote:
>>> On 07/29/2015 01:48 PM, Frederik Bayart wrote:
>>>>> On Wednesday, 29 July 2015, 12:12, Philippe Gerum <rpm@xenomai.org> wrote:
>>>>>
>>>>>
>>>>> On 07/28/2015 05:19 PM, Frederik Bayart wrote:
>>>>>>>> ./stest --session=foo 1
>>>>>>>>
>>>>>>>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>>>>>>>
>>>>>>>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>>>>>>>
>>>>>>>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>>>>>>>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>>>>>>>
>>>>>>>
>>>>>>> Looking at the copperplate code, yep, this definitely can't work. Ok,
>>>>>>> queued.
>>>>>>
>>>>>> I noticed also :
>>>>>>
>>>>>>  ./stest --session=foo 1
>>>>>>  ./stest --session=foo 0
>>>>>>
>>>>>> Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised.
>>>>>
>>>>>
>>>>> Spurious wake up in the Cobalt kernel when aborting a sem wait operation
>>>>> due to a signal/unblock event, that is the reason why I could not see
>>>>> this from a Mercury setup. This is fixed in the -next branch.
>>>>>
>>>>>> At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>>>>>
>>>>> I don't observe this one. Assuming you enabled the registry, what does
>>>>> /var/run/xenomai/.../alchemy/semaphores/semtestsem tell you about the
>>>>> sema4 value?
>>>>>
>>>>
>>>> When I start my processes, I don't see this alchemy directory in my registry. Any suggestion why ?
>>>>
>>>> The output of 'xeno-config --info' is :
>>>>
>>>> Xenomai version: Xenomai/cobalt v3.0-rc5 --
>>>> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc5 #1 SMP PREEMPT Fri Jul 10 12:29:14 CEST 2015 x86_64 GNU/Linux
>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc5 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>>>> I-pipe release #1 detected
>>>> Cobalt core 3.0-rc5 detected
>>>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>>>> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>>>>
>>>> I have only this in the registery :
>>>>
>>>> find /var/run/xenomai
>>>>
>>>> /var/run/xenomai
>>>> /var/run/xenomai/root
>>>> /var/run/xenomai/root/foo
>>>> /var/run/xenomai/root/foo/6210
>>>> /var/run/xenomai/root/foo/6203
>>>> /var/run/xenomai/root/foo/system
>>>>
>>>>
>>>> In attachment my latest version of stest.c to be sure, there are only small modifications.
>>>>
>>>> Below the output of the first process
>>>>
>>>> sudo ./stest --session=foo 1
>>>> stest.c:82: __XENO_COMPAT__ not defined, create = 1
>>>> stest.c:121: enter CTRL+C to continue...
>>>> stest.c:43: binding sem semtestsem...
>>>> stest.c:51: calling rt_sem_p...
>>>> ========= Now CTRL+C on the second (other) process ======================
>>>> stest.c:60: rt_sem_p passed
>>>
>>> You must mean interrupting the one enabling create mode, i.e.
>>> --session=foo 1. ^C on the other one will terminate it immediately since
>>> it does not trap this signal, leaving the first one hanging on
>>> rt_sem_p() as expected (with the latest fix applied).
>>>
>>>> ========= Now CTRL+C on this (first) process to interrupt the wait loop =========
>>>> stest.c:32: signal(2)
>>>> stest.c:146: nwaiters = 1
>>>> stest.c:147: count = 0
>>>> stest.c:152: calling rt_sem_v 1...
>>>> stest.c:161: rt_sem_v called
>>>> stest.c:186: nwaiters = 0
>>>> stest.c:187: count = 0
>>>>
>>>
>>> Looking at your code, I fail to see any issue with this trace output.
>>> What output would you expect instead?
>>
>> I switched to rc6 (kernel and libraries)
>>
>> Concerning the registry : 
>>
>> The fuse module is loaded :
>> $ lsmod | grep fuse
>> fuse                   87410  7 
>>
>> $ sudo ./stest  --dump-config|grep REGISTRY
>> based on Xenomai/cobalt v3.0-rc6 -- 
>> CONFIG_XENO_REGISTRY=1
>> CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
>>
>> Is this what I'm supposed to see ?
>>
>> Before start of the processes :
>>
>> $ find /var/run/xenomai/
>> /var/run/xenomai/
>> /var/run/xenomai/root
>>
>> After start of processes
>>
>> $ find /var/run/xenomai/
>> /var/run/xenomai/
>> /var/run/xenomai/root
>> /var/run/xenomai/root/foo
>> /var/run/xenomai/root/foo/4910
>> /var/run/xenomai/root/foo/4899
>> /var/run/xenomai/root/foo/system
>>
>> $ mount | grep xenomai
>> sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>> stest on /run/xenomai/root/foo/4899 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>> stest on /run/xenomai/root/foo/4910 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>>
>> So I haven't any idea why I don't see more subdirectories.
>>
>> Now concerning the semaphore :
>>
>> $cat /proc/xenomai/sched/threads | grep rt
>> 3  4899   rt     cobalt      0   -             X          main
>> 3  4902   rt     cobalt      0   -             X          sysregd
>> 3  4904   rt     cobalt      0   -             X          sysregd
>> 3  4906   rt     cobalt      0   -             X          stest
>> 3  4907   rt     cobalt    256   -             W          remote-agent
>> 3  4908   rt     cobalt     40   -             W          4899test
>> 0  4910   rt     cobalt      0   -             X          main
>> 0  4912   rt     cobalt      0   -             X          stest
>> 0  4913   rt     cobalt    256   -             W          remote-agent
>> 0  4914   rt     cobalt     40   -             W          4910test
>>
>>
>> Now I enter CTRL+C on the second process (the non-creating process). The SIGINT signal is not catched in this process. The second process is ended.
>>
>> $cat /proc/xenomai/sched/threads | grep rt
>> 3  4899   rt     cobalt      0   -             X          main
>> 3  4902   rt     cobalt      0   -             X          sysregd
>> 3  4904   rt     cobalt      0   -             X          sysregd
>> 3  4906   rt     cobalt      0   -             X          stest
>> 3  4907   rt     cobalt    256   -             W          remote-agent
>>
>>
>> The rt_sem_p call in the first process also returns with return value 0.
>> This has as consequence that the task 4899test of the first process is also ended.
> 
> Please merge the commit on top of -rc6 I mentioned this morning, which
> fixes the spurious wake up:
> 
> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
> 

Actually, I did not mention it, that's why we don't seem to be on the
same page, sorry for this. We should resume the discussion from the
situation obtained with this commit on top of -rc6.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>
>> Please merge the commit on top of -rc6 I mentioned this morning, which
>> fixes the spurious wake up:
>>
>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>
>
>Actually, I did not mention it, that's why we don't seem to be on the
>same page, sorry for this. We should resume the discussion from the
>situation obtained with this commit on top of -rc6.

I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
The rt_sem_p problem is now solved, the first process is not interrupted anymore.

I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.

I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
But the select doesn't seem to react on connect. I'm looking at the problem.

Maybe I will see more if I build with --enable-debug.

This is the fuse data of the system :

$ sudo ./stest  --dump-config|grep REGISTRY
based on Xenomai/cobalt v3.0-rc6 -- 
CONFIG_XENO_REGISTRY=1
CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"

Is this what I'm supposed to see ?

I configured CONFIG_FUSE_FS=m in the kernel, module fuse is loaded.
The fuse packages are installed :
ii  fuse            2.9.3-15+b1  amd64    Filesystem in Userspace
ii  gvfs-fuse        1.22.2-1    amd64    userspace virtual filesystem - fuse server
ii  libfuse-dev      2.9.3-15+b1  amd64    Filesystem in Userspace (development)
ii  libfuse2:amd64  2.9.3-15+b1  amd64    Filesystem in Userspace (library)

$ xeno-config --info
Xenomai version: Xenomai/cobalt v3.0-rc6 -- 
Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc6.1 #1 SMP PREEMPT Thu Jul 30 12:38:10 CEST 2015 x86_64 GNU/Linux
Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc6.1 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
I-pipe release #1 detected
Cobalt core 3.0-rc6 detected
Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu


If I run the 2 stest processes, this is what I see :
$ find /var/run/xenomai/
/var/run/xenomai/
/var/run/xenomai/root
/var/run/xenomai/root/foo
/var/run/xenomai/root/foo/20678
/var/run/xenomai/root/foo/20667
/var/run/xenomai/root/foo/system

$ mount | grep fuse
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
stest on /run/xenomai/root/foo/20667 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
stest on /run/xenomai/root/foo/20678 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)

Frederik

>
>-- 
>Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>
>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>> fixes the spurious wake up:
>>>
>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>
>>
>>Actually, I did not mention it, that's why we don't seem to be on the
>>same page, sorry for this. We should resume the discussion from the
>>situation obtained with this commit on top of -rc6.
>
>I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>
>I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>
>I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>But the select doesn't seem to react on connect. I'm looking at the problem.


I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.

>
>Maybe I will see more if I build with --enable-debug.
>
>This is the fuse data of the system :
>
>$ sudo ./stest  --dump-config|grep REGISTRY
>based on Xenomai/cobalt v3.0-rc6 --
>CONFIG_XENO_REGISTRY=1
>CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
>
>Is this what I'm supposed to see ?
>
>I configured CONFIG_FUSE_FS=m in the kernel, module fuse is loaded.
>The fuse packages are installed :
>ii  fuse            2.9.3-15+b1  amd64    Filesystem in Userspace
>ii  gvfs-fuse        1.22.2-1    amd64    userspace virtual filesystem - fuse server
>ii  libfuse-dev      2.9.3-15+b1  amd64    Filesystem in Userspace (development)
>ii  libfuse2:amd64  2.9.3-15+b1  amd64    Filesystem in Userspace (library)
>
>$ xeno-config --info
>Xenomai version: Xenomai/cobalt v3.0-rc6 --
>Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc6.1 #1 SMP PREEMPT Thu Jul 30 12:38:10 CEST 2015 x86_64 GNU/Linux
>Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc6.1 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>I-pipe release #1 detected
>Cobalt core 3.0-rc6 detected
>Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>
>
>If I run the 2 stest processes, this is what I see :
>$ find /var/run/xenomai/
>/var/run/xenomai/
>/var/run/xenomai/root
>/var/run/xenomai/root/foo
>/var/run/xenomai/root/foo/20678
>/var/run/xenomai/root/foo/20667
>/var/run/xenomai/root/foo/system
>
>$ mount | grep fuse
>fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
>sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>stest on /run/xenomai/root/foo/20667 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>stest on /run/xenomai/root/foo/20678 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>
>
>Frederik
>
>>
>>--
>>Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>
>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>> fixes the spurious wake up:
>>>>
>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>
>>>
>>> Actually, I did not mention it, that's why we don't seem to be on the
>>> same page, sorry for this. We should resume the discussion from the
>>> situation obtained with this commit on top of -rc6.
>>
>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>
>> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>
>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>> But the select doesn't seem to react on connect. I'm looking at the problem.
> 
> 
> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.

libtrank is just an overlay on top of libalchemy, only consisting of
fairly simple wrappers. I would suspect a difference in the flags passed
to xeno-config instead.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>>
>>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>>> fixes the spurious wake up:
>>>>>
>>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>>
>>>>
>>>> Actually, I did not mention it, that's why we don't seem to be on the
>>>> same page, sorry for this. We should resume the discussion from the
>>>> situation obtained with this commit on top of -rc6.
>>>
>>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>>
>>> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>>
>>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>
>>
>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>
>libtrank is just an overlay on top of libalchemy, only consisting of
>fairly simple wrappers. I would suspect a difference in the flags passed
>to xeno-config instead.

I succeeded to start my server using alchemy directly.

Via trank the program generates a flood of error:

$ sudo ./ptest

ptest.c:68 ERROR: select(4): Interrupted system call
ptest.c:68 ERROR: select(4): Interrupted system call
ptest.c:68 ERROR: select(4): Interrupted system call
...

In attachment a test file ptest.c and makefile to reproduce the problem.

My original server uses both native and posix calls, for that I used both native and posix flags.

XENO_CFLAGS = $(shell $(XENOCONFIG) --posix  --compat --native --cflags )
XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )

With alchemy directly there is no problem :

XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)


I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :

If I link with xeno-config  --posix --ldflags --compat, I get :

cc -Wl,@/usr/lib/cobalt.wrappers -ltrank   /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt    -lfuse -pthread  -o ptest ptest.o
/usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
/usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
/usr/lib/libtrank.so: undefined reference to `rt_task_self'
/usr/lib/libtrank.so: undefined reference to `rt_task_wait_period'
/usr/lib/libtrank.so: undefined reference to `xnfree'
/usr/lib/libtrank.so: undefined reference to `__current_rt_event_create'
/usr/lib/libtrank.so: undefined reference to `rt_task_start'
/usr/lib/libtrank.so: undefined reference to `rt_task_delete'
/usr/lib/libtrank.so: undefined reference to `rt_task_set_affinity'
/usr/lib/libtrank.so: undefined reference to `rt_task_suspend'
/usr/lib/libtrank.so: undefined reference to `__current_rt_event_clear'
/usr/lib/libtrank.so: undefined reference to `threadobj_irq_prio'
/usr/lib/libtrank.so: undefined reference to `__current_rt_event_signal'
/usr/lib/libtrank.so: undefined reference to `__current_rt_task_create'
/usr/lib/libtrank.so: undefined reference to `__current_rt_task_set_periodic'
/usr/lib/libtrank.so: undefined reference to `__current_rt_pipe_create'
/usr/lib/libtrank.so: undefined reference to `__threadobj_current'
/usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
/usr/lib/libtrank.so: undefined reference to `xnmalloc'
collect2: error: ld returned 1 exit status
makefile:27: recipe for target 'ptest' failed
make: *** [ptest] Error 1

With the --native flag added, this is solved because  -lalchemy -lcopperplate is then added.

Frederik

>
>
>-- 
>Philippe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 773 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150731/63e2eefc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptest.c
Type: text/x-csrc
Size: 3831 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150731/63e2eefc/attachment.c>

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/31/2015 07:54 PM, Frederik Bayart wrote:
>> On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>> On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>>>
>>>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>>>> fixes the spurious wake up:
>>>>>>
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>>>
>>>>>
>>>>> Actually, I did not mention it, that's why we don't seem to be on the
>>>>> same page, sorry for this. We should resume the discussion from the
>>>>> situation obtained with this commit on top of -rc6.
>>>>
>>>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>>>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>>>
>>>> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>>>
>>>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>>
>>>
>>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>>
>> libtrank is just an overlay on top of libalchemy, only consisting of
>> fairly simple wrappers. I would suspect a difference in the flags passed
>> to xeno-config instead.
> 
> I succeeded to start my server using alchemy directly.
> 
> Via trank the program generates a flood of error:
> 
> $ sudo ./ptest
> 
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ...
> 
> In attachment a test file ptest.c and makefile to reproduce the problem.
> 

Ok, I'll have a look.

> My original server uses both native and posix calls, for that I used both native and posix flags.
> 
> XENO_CFLAGS = $(shell $(XENOCONFIG) --posix  --compat --native --cflags )
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )
> 

--compat --native is redundant, --native enables --compat implicitly.
--alchemy does not.

> With alchemy directly there is no problem :
> 
> XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)
> 
> 
> I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :
> 
> If I link with xeno-config  --posix --ldflags --compat, I get :
> 
> cc -Wl,@/usr/lib/cobalt.wrappers -ltrank   /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt    -lfuse -pthread  -o ptest ptest.o
> /usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_self'
> /usr/lib/libtrank.so: undefined reference to `rt_task_wait_period'
> /usr/lib/libtrank.so: undefined reference to `xnfree'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_start'
> /usr/lib/libtrank.so: undefined reference to `rt_task_delete'
> /usr/lib/libtrank.so: undefined reference to `rt_task_set_affinity'
> /usr/lib/libtrank.so: undefined reference to `rt_task_suspend'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_clear'
> /usr/lib/libtrank.so: undefined reference to `threadobj_irq_prio'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_signal'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_create'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_set_periodic'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_pipe_create'
> /usr/lib/libtrank.so: undefined reference to `__threadobj_current'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
> /usr/lib/libtrank.so: undefined reference to `xnmalloc'
> collect2: error: ld returned 1 exit status
> makefile:27: recipe for target 'ptest' failed
> make: *** [ptest] Error 1
> 
> With the --native flag added, this is solved because  -lalchemy -lcopperplate is then added.
> 

This is expected, compat mode is aimed at the legacy native API only.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/31/2015 07:54 PM, Frederik Bayart wrote:
>> On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>> On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>>>
>>>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>>>> fixes the spurious wake up:
>>>>>>
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>>>
>>>>>
>>>>> Actually, I did not mention it, that's why we don't seem to be on the
>>>>> same page, sorry for this. We should resume the discussion from the
>>>>> situation obtained with this commit on top of -rc6.
>>>>
>>>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>>>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>>>
>>>> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>>>
>>>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>>
>>>
>>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>>
>> libtrank is just an overlay on top of libalchemy, only consisting of
>> fairly simple wrappers. I would suspect a difference in the flags passed
>> to xeno-config instead.
> 
> I succeeded to start my server using alchemy directly.
> 
> Via trank the program generates a flood of error:
> 
> $ sudo ./ptest
> 
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ...
> 
> In attachment a test file ptest.c and makefile to reproduce the problem.
> 
> My original server uses both native and posix calls, for that I used both native and posix flags.
> 
> XENO_CFLAGS = $(shell $(XENOCONFIG) --posix  --compat --native --cflags )
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )
> 
> With alchemy directly there is no problem :
> 
> XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)
> 
> 
> I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :
> 
> If I link with xeno-config  --posix --ldflags --compat, I get :
> 
> cc -Wl,@/usr/lib/cobalt.wrappers -ltrank   /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt    -lfuse -pthread  -o ptest ptest.o
> /usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_self'
> /usr/lib/libtrank.so: undefined reference to `rt_task_wait_period'
> /usr/lib/libtrank.so: undefined reference to `xnfree'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_start'
> /usr/lib/libtrank.so: undefined reference to `rt_task_delete'
> /usr/lib/libtrank.so: undefined reference to `rt_task_set_affinity'
> /usr/lib/libtrank.so: undefined reference to `rt_task_suspend'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_clear'
> /usr/lib/libtrank.so: undefined reference to `threadobj_irq_prio'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_signal'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_create'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_set_periodic'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_pipe_create'
> /usr/lib/libtrank.so: undefined reference to `__threadobj_current'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
> /usr/lib/libtrank.so: undefined reference to `xnmalloc'
> collect2: error: ld returned 1 exit status
> makefile:27: recipe for target 'ptest' failed
> make: *** [ptest] Error 1
> 
> With the --native flag added, this is solved because  -lalchemy -lcopperplate is then added.

The issue is not between --alchemy and --native, but with --posix being
added or not. I could not reproduce this behavior (x86, ppc or arm)
using your exact test code (I can see timeouts triggering each 5s), but
looking at it, I'm pretty sure this is due to passing regular linux fds
(from socket(AF_UNIX) to RTDM services.

When --posix is given, select(), socket() and friends will be routed to
RTDM _first_, which will check whether the corresponding channels are
connected to a real-time driver. If the fds are not managed by RTDM, the
call will be redirected to the glibc eventually. I don't explain why
your code receives EINTR from RTDM's select() yet, but this is most
likely not related to libtrank. This behavior is unexpected though, so
we have to find why Xenomai's select() behaves like this.

In the meantime, if you want to mix Xenomai/POSIX calls with regular
glibc ones when --posix is in effect, you can alternatively:

- tag all regular POSIX calls for which a Xenomai counterpart exist with
__STD(call(args))
- invoke __real_call(args)

Alternatively, you can drop --posix which will disable the POSIX
wrapping for your code, then invoke __RT(call(args)) explicitly for
Xenomai real-time services.

Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

Sorry for previous mail with no additional content, yahoo mail client is very sensitive apparently.

> On Saturday, 1 August 2015, 10:43, Philippe Gerum <rpm@xenomai.org> wrote:
>On 07/31/2015 07:54 PM, Frederik Bayart wrote:
>>> On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>>> On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>>>
>>>>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>>>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>>>
>>>>
>>>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>>>
>>> libtrank is just an overlay on top of libalchemy, only consisting of
>>> fairly simple wrappers. I would suspect a difference in the flags passed
>>> to xeno-config instead.
>>
>> I succeeded to start my server using alchemy directly.
>>
>> Via trank the program generates a flood of error:
>>
>> $ sudo ./ptest
>>
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ...
>>
>> In attachment a test file ptest.c and makefile to reproduce the problem.
>>
>> My original server uses both native and posix calls, for that I used both native and posix flags.
>>
>> XENO_CFLAGS = $(shell $(XENOCONFIG) --posix  --compat --native --cflags )
>> XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )
>>
>> With alchemy directly there is no problem :
>>
>> XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
>> XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)
>>
>>
>> I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :
>>
>> If I link with xeno-config  --posix --ldflags --compat, I get :
>>
>> cc -Wl,@/usr/lib/cobalt.wrappers -ltrank  /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt    -lfuse -pthread  -o ptest ptest.o
>> /usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
>> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
>> /usr/lib/libtrank.so: undefined reference to `rt_task_self'
>...
>> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
>> /usr/lib/libtrank.so: undefined reference to `xnmalloc'
>> collect2: error: ld returned 1 exit status
>> makefile:27: recipe for target 'ptest' failed
>> make: *** [ptest] Error 1
>>
>> With the --native flag added, this is solved because  -lalchemy -lcopperplate is then added.
>
>The issue is not between --alchemy and --native, but with --posix being
>added or not. I could not reproduce this behavior (x86, ppc or arm)
>using your exact test code (I can see timeouts triggering each 5s), but
>looking at it, I'm pretty sure this is due to passing regular linux fds
>(from socket(AF_UNIX) to RTDM services.
>
>When --posix is given, select(), socket() and friends will be routed to
>RTDM _first_, which will check whether the corresponding channels are
>connected to a real-time driver. If the fds are not managed by RTDM, the
>call will be redirected to the glibc eventually. I don't explain why
>your code receives EINTR from RTDM's select() yet, but this is most
>likely not related to libtrank. This behavior is unexpected though, so
>we have to find why Xenomai's select() behaves like this.

If I can help, let me know, then I try to make some time to look at it.
If you can't reproduce the problem, I could always run some test program on my PC.
What is the best way to debug it ?
Just to exclude : could it be an installation issue ?

Have you xenomai installed in /usr/xenomai/... ?
I'm using debian installation so that could be a difference. Any hardcoded library paths ?

Frederik

>
>In the meantime, if you want to mix Xenomai/POSIX calls with regular
>glibc ones when --posix is in effect, you can alternatively:
>
>- tag all regular POSIX calls for which a Xenomai counterpart exist with
>__STD(call(args))
>- invoke __real_call(args)
>
>Alternatively, you can drop --posix which will disable the POSIX
>wrapping for your code, then invoke __RT(call(args)) explicitly for
>Xenomai real-time services.
>
>Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/30/2015 04:28 PM, Frederik Bayart wrote:

> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
> But the select doesn't seem to react on connect. I'm looking at the problem.
> 

It all depends on the flags passed to xeno-config (*): if --posix or
--rtdm is given (alone, or along with --native, --alchemy or whatever
other non-POSIX API), then POSIX calls will be wrapped to the
Xenomai/cobalt counterparts, in which case select() would call the
Xenomai implementation for instance.

If neither --posix nor --rtdm are given, then no wrapping takes place,
and select() will call the regular linux implementation.

If __real_select() works successfully in your app and differently than
select(), then wrapping is in effect, and this means that your file
descriptors are plain regular ones, obtained by standard linux syscalls
(__real_open, __real_socket), not by Xenomai syscalls (open, socket).

You may want to check for a mismatch due to POSIX symbol wrapping in
your app.

(*)
http://www.xenomai.org/documentation/xenomai-3/html/man1/xeno-config/index.html

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Philippe Gerum]

On 07/30/2015 04:28 PM, Frederik Bayart wrote:
>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>
>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>> fixes the spurious wake up:
>>>
>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>
>>
>> Actually, I did not mention it, that's why we don't seem to be on the
>> same page, sorry for this. We should resume the discussion from the
>> situation obtained with this commit on top of -rc6.
> 
> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
> 
> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
> 
> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
> But the select doesn't seem to react on connect. I'm looking at the problem.
> 
> Maybe I will see more if I build with --enable-debug.
> 
> This is the fuse data of the system :
> 
> $ sudo ./stest  --dump-config|grep REGISTRY
> based on Xenomai/cobalt v3.0-rc6 -- 
> CONFIG_XENO_REGISTRY=1
> CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
> 
> Is this what I'm supposed to see ?
>

Yes.

> I configured CONFIG_FUSE_FS=m in the kernel, module fuse is loaded.
> The fuse packages are installed :
> ii  fuse            2.9.3-15+b1  amd64    Filesystem in Userspace
> ii  gvfs-fuse        1.22.2-1    amd64    userspace virtual filesystem - fuse server
> ii  libfuse-dev      2.9.3-15+b1  amd64    Filesystem in Userspace (development)
> ii  libfuse2:amd64  2.9.3-15+b1  amd64    Filesystem in Userspace (library)
> 
> $ xeno-config --info
> Xenomai version: Xenomai/cobalt v3.0-rc6 -- 
> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc6.1 #1 SMP PREEMPT Thu Jul 30 12:38:10 CEST 2015 x86_64 GNU/Linux
> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc6.1 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
> I-pipe release #1 detected
> Cobalt core 3.0-rc6 detected
> Compiler: gcc version 4.9.2 (Debian 4.9.2-10) 
> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
> 
> 
> If I run the 2 stest processes, this is what I see :
> $ find /var/run/xenomai/
> /var/run/xenomai/
> /var/run/xenomai/root
> /var/run/xenomai/root/foo
> /var/run/xenomai/root/foo/20678
> /var/run/xenomai/root/foo/20667
> /var/run/xenomai/root/foo/system
> 
> $ mount | grep fuse
> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
> sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
> stest on /run/xenomai/root/foo/20667 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
> stest on /run/xenomai/root/foo/20678 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)

I suspect a permission issue, since you attempt to traverse the mount
points apparently with regular user privileges. Any luck with "sudo find
..." ?

Alternatively, passing --shared-registry to your app would enable public
access to the registry of your application.

-- 
Philippe.

Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart]

>On Thursday, 30 July 2015, 18:36, Philippe Gerum <rpm@xenomai.org> wrote:
>On 07/30/2015 04:28 PM, Frederik Bayart wrote:
>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>
>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>> fixes the spurious wake up:
>>>>
>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>
>>>
>>> Actually, I did not mention it, that's why we don't seem to be on the
>>> same page, sorry for this. We should resume the discussion from the
>>> situation obtained with this commit on top of -rc6.
>>
>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>
>> I still doesn't see the fuse file system like you do.  I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>
>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>
>> Maybe I will see more if I build with --enable-debug.
>>
>> This is the fuse data of the system :
>>
>> $ sudo ./stest  --dump-config|grep REGISTRY
>> based on Xenomai/cobalt v3.0-rc6 --
>> CONFIG_XENO_REGISTRY=1
>> CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
>>
>> Is this what I'm supposed to see ?
>>
>
>Yes.
>
>> I configured CONFIG_FUSE_FS=m in the kernel, module fuse is loaded.
>> The fuse packages are installed :
>> ii  fuse            2.9.3-15+b1  amd64    Filesystem in Userspace
>> ii  gvfs-fuse        1.22.2-1    amd64    userspace virtual filesystem - fuse server
>> ii  libfuse-dev      2.9.3-15+b1  amd64    Filesystem in Userspace (development)
>> ii  libfuse2:amd64  2.9.3-15+b1  amd64    Filesystem in Userspace (library)
>>
>> $ xeno-config --info
>> Xenomai version: Xenomai/cobalt v3.0-rc6 --
>> Linux dev-x10sae 3.18.12-x86-64-xeno-3.0.rc6.1 #1 SMP PREEMPT Thu Jul 30 12:38:10 CEST 2015 x86_64 GNU/Linux
>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-3.18.12-x86-64-xeno-3.0.rc6.1 root=UUID=fc8ecefa-fc73-487f-a045-cffa99c38a11 ro quiet console=tty0 console=ttyS0,115200n8
>> I-pipe release #1 detected
>> Cobalt core 3.0-rc6 detected
>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>> Build args: --prefix=/usr --includedir=/usr/include/xenomai --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite --with-core=cobalt --enable-smp --enable-pshared --enable-registry --build x86_64-linux-gnu build_alias=x86_64-linux-gnu
>>
>>
>> If I run the 2 stest processes, this is what I see :
>> $ find /var/run/xenomai/
>> /var/run/xenomai/
>> /var/run/xenomai/root
>> /var/run/xenomai/root/foo
>> /var/run/xenomai/root/foo/20678
>> /var/run/xenomai/root/foo/20667
>> /var/run/xenomai/root/foo/system
>>
>> $ mount | grep fuse
>> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
>> sysregd on /run/xenomai/root/foo/system type fuse.sysregd (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>> stest on /run/xenomai/root/foo/20667 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>> stest on /run/xenomai/root/foo/20678 type fuse.stest (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)
>
>I suspect a permission issue, since you attempt to traverse the mount
>points apparently with regular user privileges. Any luck with "sudo find
>..." ?
>
>Alternatively, passing --shared-registry to your app would enable public
>access to the registry of your application.

This was the cause, thank you !

Frederik
>
>-- 
>Philippe.