[Xenomai] Cannot initialize TLSF memory manager

[Xenomai] Cannot initialize TLSF memory manager

[Leopold Palomo-Avellaneda]

Hi,


I have seen this bug before, but it seems that it's again in 3.0.6. Running
3.0.6 with:

 xeno-config --info
Xenomai version: Xenomai/cobalt v3.0.6
Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
GNU/Linux
Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
xenomai.allowed_group=113 nosmap
I-pipe release #4 detected
Cobalt core 3.0.6 detected
Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
Build args: --build=x86_64-linux-gnu --includedir=/usr/include
--mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
--localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
--libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
--mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
--enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
--enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
--enable-smp --with-core=cobalt --build x86_64-linux-gnu
build_alias=x86_64-linux-gnu CFLAGS=-g -O2
-fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2



when I try xeno-test, I got:

 xeno-test
Started child 2593: /bin/bash
/usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
++ echo 0
++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
init_memory_pool(): invalid pool
   0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
memory manager


Any idea?

Best regards,

Leopold



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Cannot initialize TLSF memory manager

[Philippe Gerum]

On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> 
> I have seen this bug before, but it seems that it's again in 3.0.6. Running
> 3.0.6 with:
> 
>  xeno-config --info
> Xenomai version: Xenomai/cobalt v3.0.6
> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
> GNU/Linux
> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
> xenomai.allowed_group=113 nosmap
> I-pipe release #4 detected
> Cobalt core 3.0.6 detected
> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
> -D_FORTIFY_SOURCE=2
> 
> 
> 
> when I try xeno-test, I got:
> 
>  xeno-test
> Started child 2593: /bin/bash
> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
> ++ echo 0
> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
> init_memory_pool(): invalid pool
>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
> memory manager
> 
> 
> Any idea?
> 

Can you check whether the call to tlsf_malloc() in
heapobj_pkg_init_private() returns non-NULL?
(lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?

Thanks,

-- 
Philippe.

Re: [Xenomai] Cannot initialize TLSF memory manager

[Leopold Palomo-Avellaneda]

On 23/11/17 13:22, Philippe Gerum wrote:
> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>> Hi,
>>
>>
>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>> 3.0.6 with:
>>
>>  xeno-config --info
>> Xenomai version: Xenomai/cobalt v3.0.6
>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>> GNU/Linux
>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>> xenomai.allowed_group=113 nosmap
>> I-pipe release #4 detected
>> Cobalt core 3.0.6 detected
>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>> -D_FORTIFY_SOURCE=2
>>
>>
>>
>> when I try xeno-test, I got:
>>
>>  xeno-test
>> Started child 2593: /bin/bash
>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>> ++ echo 0
>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>> init_memory_pool(): invalid pool
>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>> memory manager
>>
>>
>> Any idea?
>>
> 
> Can you check whether the call to tlsf_malloc() in
> heapobj_pkg_init_private() returns non-NULL?
> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?

Checking the code, it fails before to return anything. Running crosss-link, that
fails in the same function:
./cross-link

init_memory_pool(): invalid pool
Init memory pool returns -1 bytes
   0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
memory manager


I just added:

+      printf("Init memory pool returns %zd bytes \n", available_size);

        if (available_size == (size_t)-1)
                panic("cannot initialize TLSF memory manager");

+     printf("Running after ...\n");


in that function of the file you mentioned.

Leopold




-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171123/d634bfd1/attachment.sig>

Re: [Xenomai] Cannot initialize TLSF memory manager

[Philippe Gerum]

On 11/23/2017 03:58 PM, Leopold Palomo-Avellaneda wrote:
> On 23/11/17 13:22, Philippe Gerum wrote:
>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>> Hi,
>>>
>>>
>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>> 3.0.6 with:
>>>
>>>  xeno-config --info
>>> Xenomai version: Xenomai/cobalt v3.0.6
>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>> GNU/Linux
>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>> xenomai.allowed_group=113 nosmap
>>> I-pipe release #4 detected
>>> Cobalt core 3.0.6 detected
>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>> -D_FORTIFY_SOURCE=2
>>>
>>>
>>>
>>> when I try xeno-test, I got:
>>>
>>>  xeno-test
>>> Started child 2593: /bin/bash
>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>> ++ echo 0
>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>> init_memory_pool(): invalid pool
>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>> memory manager
>>>
>>>
>>> Any idea?
>>>
>>
>> Can you check whether the call to tlsf_malloc() in
>> heapobj_pkg_init_private() returns non-NULL?
>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
> 
> Checking the code, it fails before to return anything. Running crosss-link, that
> fails in the same function:
> ./cross-link
> 
> init_memory_pool(): invalid pool
> Init memory pool returns -1 bytes
>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
> memory manager
> 
> 
> I just added:
> 
> +      printf("Init memory pool returns %zd bytes \n", available_size);
> 
>         if (available_size == (size_t)-1)
>                 panic("cannot initialize TLSF memory manager");
> 
> +     printf("Running after ...\n");
> 
> 
> in that function of the file you mentioned.
> 

Can you try this?

diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
index 370985210..0186be423 100644
--- a/lib/copperplate/heapobj-tlsf.c
+++ b/lib/copperplate/heapobj-tlsf.c
@@ -103,6 +103,7 @@ int heapobj_pkg_init_private(void)
 	 * out the allocation overhead.
 	 */
 	mem = tlsf_malloc(alloc_size);
+	printf("mem=%p, alloc_size=%zu\n", mem, alloc_size);
 	available_size = init_memory_pool(alloc_size, mem);
 	if (available_size == (size_t)-1)
 		panic("cannot initialize TLSF memory manager");

-- 
Philippe.

Re: [Xenomai] Cannot initialize TLSF memory manager

[Leopold Palomo-Avellaneda]

On 23/11/17 15:58, Leopold Palomo-Avellaneda wrote:
> On 23/11/17 13:22, Philippe Gerum wrote:
>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>> Hi,
>>>
>>>
>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>> 3.0.6 with:
>>>
>>>  xeno-config --info
>>> Xenomai version: Xenomai/cobalt v3.0.6
>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>> GNU/Linux
>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>> xenomai.allowed_group=113 nosmap
>>> I-pipe release #4 detected
>>> Cobalt core 3.0.6 detected
>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>> -D_FORTIFY_SOURCE=2
>>>
>>>
>>>
>>> when I try xeno-test, I got:
>>>
>>>  xeno-test
>>> Started child 2593: /bin/bash
>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>> ++ echo 0
>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>> init_memory_pool(): invalid pool
>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>> memory manager
>>>
>>>
>>> Any idea?
>>>
>>
>> Can you check whether the call to tlsf_malloc() in
>> heapobj_pkg_init_private() returns non-NULL?
>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
> 
> Checking the code, it fails before to return anything. Running crosss-link, that
> fails in the same function:
> ./cross-link
> 
> init_memory_pool(): invalid pool
> Init memory pool returns -1 bytes
>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
> memory manager
> 
> 
> I just added:
> 
> +      printf("Init memory pool returns %zd bytes \n", available_size);
> 
>         if (available_size == (size_t)-1)
>                 panic("cannot initialize TLSF memory manager");
> 
> +     printf("Running after ...\n");
> 
> 
> in that function of the file you mentioned.

just for FYI, if I build xenomain without pshared it works ....

Leopold



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Cannot initialize TLSF memory manager

[Leopold Palomo-Avellaneda]

On 23/11/17 16:04, Philippe Gerum wrote:
> On 11/23/2017 03:58 PM, Leopold Palomo-Avellaneda wrote:
>> On 23/11/17 13:22, Philippe Gerum wrote:
>>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>> Hi,
>>>>
>>>>
>>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>>> 3.0.6 with:
>>>>
>>>>  xeno-config --info
>>>> Xenomai version: Xenomai/cobalt v3.0.6
>>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>>> GNU/Linux
>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>>> xenomai.allowed_group=113 nosmap
>>>> I-pipe release #4 detected
>>>> Cobalt core 3.0.6 detected
>>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>>> -D_FORTIFY_SOURCE=2
>>>>
>>>>
>>>>
>>>> when I try xeno-test, I got:
>>>>
>>>>  xeno-test
>>>> Started child 2593: /bin/bash
>>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>>> ++ echo 0
>>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>>> init_memory_pool(): invalid pool
>>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>> memory manager
>>>>
>>>>
>>>> Any idea?
>>>>
>>>
>>> Can you check whether the call to tlsf_malloc() in
>>> heapobj_pkg_init_private() returns non-NULL?
>>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
>>
>> Checking the code, it fails before to return anything. Running crosss-link, that
>> fails in the same function:
>> ./cross-link
>>
>> init_memory_pool(): invalid pool
>> Init memory pool returns -1 bytes
>>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>> memory manager
>>
>>
>> I just added:
>>
>> +      printf("Init memory pool returns %zd bytes \n", available_size);
>>
>>         if (available_size == (size_t)-1)
>>                 panic("cannot initialize TLSF memory manager");
>>
>> +     printf("Running after ...\n");
>>
>>
>> in that function of the file you mentioned.
>>
> 
> Can you try this?
> 
> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
> index 370985210..0186be423 100644
> --- a/lib/copperplate/heapobj-tlsf.c
> +++ b/lib/copperplate/heapobj-tlsf.c
> @@ -103,6 +103,7 @@ int heapobj_pkg_init_private(void)
>  	 * out the allocation overhead.
>  	 */
>  	mem = tlsf_malloc(alloc_size);
> +	printf("mem=%p, alloc_size=%zu\n", mem, alloc_size);
>  	available_size = init_memory_pool(alloc_size, mem);
>  	if (available_size == (size_t)-1)
>  		panic("cannot initialize TLSF memory manager");
> 
./cross-link
mem=0x7f70b739a8e0, alloc_size=4096
init_memory_pool(): invalid pool
Init memory pool returns -1 bytes
   0"000.029| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
memory manager

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Cannot initialize TLSF memory manager

[Philippe Gerum]

On 11/23/2017 04:08 PM, Leopold Palomo-Avellaneda wrote:
> On 23/11/17 16:04, Philippe Gerum wrote:
>> On 11/23/2017 03:58 PM, Leopold Palomo-Avellaneda wrote:
>>> On 23/11/17 13:22, Philippe Gerum wrote:
>>>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>>>> 3.0.6 with:
>>>>>
>>>>>  xeno-config --info
>>>>> Xenomai version: Xenomai/cobalt v3.0.6
>>>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>>>> GNU/Linux
>>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>>>> xenomai.allowed_group=113 nosmap
>>>>> I-pipe release #4 detected
>>>>> Cobalt core 3.0.6 detected
>>>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>>>> -D_FORTIFY_SOURCE=2
>>>>>
>>>>>
>>>>>
>>>>> when I try xeno-test, I got:
>>>>>
>>>>>  xeno-test
>>>>> Started child 2593: /bin/bash
>>>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>>>> ++ echo 0
>>>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>>>> init_memory_pool(): invalid pool
>>>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>>> memory manager
>>>>>
>>>>>
>>>>> Any idea?
>>>>>
>>>>
>>>> Can you check whether the call to tlsf_malloc() in
>>>> heapobj_pkg_init_private() returns non-NULL?
>>>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
>>>
>>> Checking the code, it fails before to return anything. Running crosss-link, that
>>> fails in the same function:
>>> ./cross-link
>>>
>>> init_memory_pool(): invalid pool
>>> Init memory pool returns -1 bytes
>>>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>> memory manager
>>>
>>>
>>> I just added:
>>>
>>> +      printf("Init memory pool returns %zd bytes \n", available_size);
>>>
>>>         if (available_size == (size_t)-1)
>>>                 panic("cannot initialize TLSF memory manager");
>>>
>>> +     printf("Running after ...\n");
>>>
>>>
>>> in that function of the file you mentioned.
>>>
>>
>> Can you try this?
>>
>> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
>> index 370985210..0186be423 100644
>> --- a/lib/copperplate/heapobj-tlsf.c
>> +++ b/lib/copperplate/heapobj-tlsf.c
>> @@ -103,6 +103,7 @@ int heapobj_pkg_init_private(void)
>>  	 * out the allocation overhead.
>>  	 */
>>  	mem = tlsf_malloc(alloc_size);
>> +	printf("mem=%p, alloc_size=%zu\n", mem, alloc_size);
>>  	available_size = init_memory_pool(alloc_size, mem);
>>  	if (available_size == (size_t)-1)
>>  		panic("cannot initialize TLSF memory manager");
>>
> ./cross-link
> mem=0x7f70b739a8e0, alloc_size=4096
> init_memory_pool(): invalid pool
> Init memory pool returns -1 bytes
>    0"000.029| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
> memory manager
> 

Ok, so please try this:

diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
index 370985210..948f7fc52 100644
--- a/lib/copperplate/heapobj-tlsf.c
+++ b/lib/copperplate/heapobj-tlsf.c
@@ -78,7 +78,7 @@ int heapobj_init_array_private(struct heapobj *hobj, const char *name,
 int heapobj_pkg_init_private(void)
 {
 	#ifdef CONFIG_XENO_PSHARED
-		size_t alloc_size = sysconf(_SC_PAGE_SIZE);
+		size_t alloc_size = sysconf(_SC_PAGE_SIZE) * 2;
 	#else
 		size_t alloc_size = __copperplate_setup_data.mem_pool;
 	#endif


-- 
Philippe.

Re: [Xenomai] Cannot initialize TLSF memory manager

[Leopold Palomo-Avellaneda]

On 23/11/17 16:12, Philippe Gerum wrote:
> On 11/23/2017 04:08 PM, Leopold Palomo-Avellaneda wrote:
>> On 23/11/17 16:04, Philippe Gerum wrote:
>>> On 11/23/2017 03:58 PM, Leopold Palomo-Avellaneda wrote:
>>>> On 23/11/17 13:22, Philippe Gerum wrote:
>>>>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>>>>> 3.0.6 with:
>>>>>>
>>>>>>  xeno-config --info
>>>>>> Xenomai version: Xenomai/cobalt v3.0.6
>>>>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>>>>> GNU/Linux
>>>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>>>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>>>>> xenomai.allowed_group=113 nosmap
>>>>>> I-pipe release #4 detected
>>>>>> Cobalt core 3.0.6 detected
>>>>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>>>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>>>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>>>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>>>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>>>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>>>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>>>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>>>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>>>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>>>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>>>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>>>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>>>>> -D_FORTIFY_SOURCE=2
>>>>>>
>>>>>>
>>>>>>
>>>>>> when I try xeno-test, I got:
>>>>>>
>>>>>>  xeno-test
>>>>>> Started child 2593: /bin/bash
>>>>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>>>>> ++ echo 0
>>>>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>>>>> init_memory_pool(): invalid pool
>>>>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>>>> memory manager
>>>>>>
>>>>>>
>>>>>> Any idea?
>>>>>>
>>>>>
>>>>> Can you check whether the call to tlsf_malloc() in
>>>>> heapobj_pkg_init_private() returns non-NULL?
>>>>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
>>>>
>>>> Checking the code, it fails before to return anything. Running crosss-link, that
>>>> fails in the same function:
>>>> ./cross-link
>>>>
>>>> init_memory_pool(): invalid pool
>>>> Init memory pool returns -1 bytes
>>>>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>> memory manager
>>>>
>>>>
>>>> I just added:
>>>>
>>>> +      printf("Init memory pool returns %zd bytes \n", available_size);
>>>>
>>>>         if (available_size == (size_t)-1)
>>>>                 panic("cannot initialize TLSF memory manager");
>>>>
>>>> +     printf("Running after ...\n");
>>>>
>>>>
>>>> in that function of the file you mentioned.
>>>>
>>>
>>> Can you try this?
>>>
>>> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
>>> index 370985210..0186be423 100644
>>> --- a/lib/copperplate/heapobj-tlsf.c
>>> +++ b/lib/copperplate/heapobj-tlsf.c
>>> @@ -103,6 +103,7 @@ int heapobj_pkg_init_private(void)
>>>  	 * out the allocation overhead.
>>>  	 */
>>>  	mem = tlsf_malloc(alloc_size);
>>> +	printf("mem=%p, alloc_size=%zu\n", mem, alloc_size);
>>>  	available_size = init_memory_pool(alloc_size, mem);
>>>  	if (available_size == (size_t)-1)
>>>  		panic("cannot initialize TLSF memory manager");
>>>
>> ./cross-link
>> mem=0x7f70b739a8e0, alloc_size=4096
>> init_memory_pool(): invalid pool
>> Init memory pool returns -1 bytes
>>    0"000.029| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>> memory manager
>>
> 
> Ok, so please try this:
> 
> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
> index 370985210..948f7fc52 100644
> --- a/lib/copperplate/heapobj-tlsf.c
> +++ b/lib/copperplate/heapobj-tlsf.c
> @@ -78,7 +78,7 @@ int heapobj_init_array_private(struct heapobj *hobj, const char *name,
>  int heapobj_pkg_init_private(void)
>  {
>  	#ifdef CONFIG_XENO_PSHARED
> -		size_t alloc_size = sysconf(_SC_PAGE_SIZE);
> +		size_t alloc_size = sysconf(_SC_PAGE_SIZE) * 2;
>  	#else
>  		size_t alloc_size = __copperplate_setup_data.mem_pool;
>  	#endif
> 
> 

with my user

./cross-link
mem=0x7f0d630488e0, alloc_size=8192
Init memory pool returns 1808 bytes
Running after ...
sysregd:
create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
Permission denied
sysregd:
create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
Permission denied
sysregd:
create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
Permission denied
   0"610.664| WARNING: [main] cannot connect to registry daemon
   0"610.798| WARNING: [main] setup call copperplate failed
   0"610.830| BUG in __xenomai_init(): [main] initialization failed, EAGAIN

with sudo ...

leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
mem=0x7fc9e73f88e0, alloc_size=8192
Init memory pool returns 1808 bytes
Running after ...
mem=0x7f2e146318e0, alloc_size=8192
Init memory pool returns 1808 bytes
Running after ...
main : can't open /dev/rtdm/rtser0 (write), No such file or directory


seems you are near ....

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Cannot initialize TLSF memory manager

[Philippe Gerum]

On 11/23/2017 04:15 PM, Leopold Palomo-Avellaneda wrote:
> On 23/11/17 16:12, Philippe Gerum wrote:
>> On 11/23/2017 04:08 PM, Leopold Palomo-Avellaneda wrote:
>>> On 23/11/17 16:04, Philippe Gerum wrote:
>>>> On 11/23/2017 03:58 PM, Leopold Palomo-Avellaneda wrote:
>>>>> On 23/11/17 13:22, Philippe Gerum wrote:
>>>>>> On 11/23/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> I have seen this bug before, but it seems that it's again in 3.0.6. Running
>>>>>>> 3.0.6 with:
>>>>>>>
>>>>>>>  xeno-config --info
>>>>>>> Xenomai version: Xenomai/cobalt v3.0.6
>>>>>>> Linux bmm3 4.9.51-xenomai-3.0.6-ipipe #1 SMP Thu Nov 23 09:03:27 CET 2017 x86_64
>>>>>>> GNU/Linux
>>>>>>> Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.9.51-xenomai-3.0.6-ipipe
>>>>>>> root=UUID=ab96eed9-cd79-4d30-9e93-e9f32a18cca6 ro quiet
>>>>>>> xenomai.allowed_group=113 nosmap
>>>>>>> I-pipe release #4 detected
>>>>>>> Cobalt core 3.0.6 detected
>>>>>>> Compiler: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>>>>>>> Build args: --build=x86_64-linux-gnu --includedir=/usr/include
>>>>>>> --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc
>>>>>>> --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu
>>>>>>> --libexecdir=/usr/lib/x86_64-linux-gnu --disable-maintainer-mode
>>>>>>> --disable-dependency-tracking --prefix=/usr --includedir=/usr/include/xenomai
>>>>>>> --mandir=/usr/share/man --with-testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>>>> --enable-fortify --libdir=/usr/lib/x86_64-linux-gnu/ --enable-pshared
>>>>>>> --enable-registry --enable-doc-build --enable-dlopen-libs --enable-tls
>>>>>>> --enable-smp --with-core=cobalt --build x86_64-linux-gnu
>>>>>>> build_alias=x86_64-linux-gnu CFLAGS=-g -O2
>>>>>>> -fdebug-prefix-map=/build/xenomai-3.0.6+ds1=. -fstack-protector-strong -Wformat
>>>>>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer
>>>>>>> LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time
>>>>>>> -D_FORTIFY_SOURCE=2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> when I try xeno-test, I got:
>>>>>>>
>>>>>>>  xeno-test
>>>>>>> Started child 2593: /bin/bash
>>>>>>> /usr/lib/x86_64-linux-gnu/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test
>>>>>>> ++ echo 0
>>>>>>> ++ testdir=/usr/lib/x86_64-linux-gnu/xenomai
>>>>>>> ++ /usr/lib/x86_64-linux-gnu/xenomai/smokey --run
>>>>>>> init_memory_pool(): invalid pool
>>>>>>>    0"000.022| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>>>>> memory manager
>>>>>>>
>>>>>>>
>>>>>>> Any idea?
>>>>>>>
>>>>>>
>>>>>> Can you check whether the call to tlsf_malloc() in
>>>>>> heapobj_pkg_init_private() returns non-NULL?
>>>>>> (lib/copperplate/heapobj-tlsf.c), and print out the value of alloc_size too?
>>>>>
>>>>> Checking the code, it fails before to return anything. Running crosss-link, that
>>>>> fails in the same function:
>>>>> ./cross-link
>>>>>
>>>>> init_memory_pool(): invalid pool
>>>>> Init memory pool returns -1 bytes
>>>>>    0"000.041| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>>>> memory manager
>>>>>
>>>>>
>>>>> I just added:
>>>>>
>>>>> +      printf("Init memory pool returns %zd bytes \n", available_size);
>>>>>
>>>>>         if (available_size == (size_t)-1)
>>>>>                 panic("cannot initialize TLSF memory manager");
>>>>>
>>>>> +     printf("Running after ...\n");
>>>>>
>>>>>
>>>>> in that function of the file you mentioned.
>>>>>
>>>>
>>>> Can you try this?
>>>>
>>>> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
>>>> index 370985210..0186be423 100644
>>>> --- a/lib/copperplate/heapobj-tlsf.c
>>>> +++ b/lib/copperplate/heapobj-tlsf.c
>>>> @@ -103,6 +103,7 @@ int heapobj_pkg_init_private(void)
>>>>  	 * out the allocation overhead.
>>>>  	 */
>>>>  	mem = tlsf_malloc(alloc_size);
>>>> +	printf("mem=%p, alloc_size=%zu\n", mem, alloc_size);
>>>>  	available_size = init_memory_pool(alloc_size, mem);
>>>>  	if (available_size == (size_t)-1)
>>>>  		panic("cannot initialize TLSF memory manager");
>>>>
>>> ./cross-link
>>> mem=0x7f70b739a8e0, alloc_size=4096
>>> init_memory_pool(): invalid pool
>>> Init memory pool returns -1 bytes
>>>    0"000.029| BUG in heapobj_pkg_init_private(): [main] cannot initialize TLSF
>>> memory manager
>>>
>>
>> Ok, so please try this:
>>
>> diff --git a/lib/copperplate/heapobj-tlsf.c b/lib/copperplate/heapobj-tlsf.c
>> index 370985210..948f7fc52 100644
>> --- a/lib/copperplate/heapobj-tlsf.c
>> +++ b/lib/copperplate/heapobj-tlsf.c
>> @@ -78,7 +78,7 @@ int heapobj_init_array_private(struct heapobj *hobj, const char *name,
>>  int heapobj_pkg_init_private(void)
>>  {
>>  	#ifdef CONFIG_XENO_PSHARED
>> -		size_t alloc_size = sysconf(_SC_PAGE_SIZE);
>> +		size_t alloc_size = sysconf(_SC_PAGE_SIZE) * 2;
>>  	#else
>>  		size_t alloc_size = __copperplate_setup_data.mem_pool;
>>  	#endif
>>
>>
> 
> with my user
> 
> ./cross-link
> mem=0x7f0d630488e0, alloc_size=8192
> Init memory pool returns 1808 bytes
> Running after ...
> sysregd:
> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
> Permission denied
> sysregd:
> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
> Permission denied
> sysregd:
> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
> Permission denied
>    0"610.664| WARNING: [main] cannot connect to registry daemon
>    0"610.798| WARNING: [main] setup call copperplate failed
>    0"610.830| BUG in __xenomai_init(): [main] initialization failed, EAGAIN
> 
> with sudo ...
> 
> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
> mem=0x7fc9e73f88e0, alloc_size=8192
> Init memory pool returns 1808 bytes
> Running after ...
> mem=0x7f2e146318e0, alloc_size=8192
> Init memory pool returns 1808 bytes
> Running after ...
> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
> 
> 
> seems you are near ....
> 

The two issues are unrelated AFAICT. The memory init issue is gone, and
I can explain why. The Permission denied issue is odd though, and you
may want to check /var/run/xenomai for perms.

Not being able to open rtser0 is yet another kind of problem: the uart
driver is not up and running, so the devices were not created. crosslink
definitely needs such driver.

-- 
Philippe.

[Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Leopold Palomo-Avellaneda]

Hi (again)

running cross-link I got that:

>> with my user
>>
>> ./cross-link
>> mem=0x7f0d630488e0, alloc_size=8192
>> Init memory pool returns 1808 bytes
>> Running after ...
>> sysregd:
>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>> Permission denied

....


the permissions are:
$ ls -la /var/run/xenomai/
total 0
drwxr-xr-x  3 root root  60 nov 23 16:03 .
drwxr-xr-x 24 root root 860 nov 24 11:12 ..
drwxr-xr-x  2 root root  40 nov 24 11:12 root

so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?

Changing the permissions manually solved it. It's something about the packaging
or the library?


>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>> mem=0x7fc9e73f88e0, alloc_size=8192
>> Init memory pool returns 1808 bytes
>> Running after ...
>> mem=0x7f2e146318e0, alloc_size=8192
>> Init memory pool returns 1808 bytes
>> Running after ...
>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory

> 
> Not being able to open rtser0 is yet another kind of problem: the uart
> driver is not up and running, so the devices were not created. crosslink
> definitely needs such driver.

Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?

Also, /dev/cpu_dma_latency should not belongs to xenomai group?

Best regards,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Philippe Gerum]

On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
> Hi (again)
> 
> running cross-link I got that:
> 
>>> with my user
>>>
>>> ./cross-link
>>> mem=0x7f0d630488e0, alloc_size=8192
>>> Init memory pool returns 1808 bytes
>>> Running after ...
>>> sysregd:
>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>> Permission denied
> 
> ....
> 
> 
> the permissions are:
> $ ls -la /var/run/xenomai/
> total 0
> drwxr-xr-x  3 root root  60 nov 23 16:03 .
> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
> drwxr-xr-x  2 root root  40 nov 24 11:12 root
> 
> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?

There is no such official "Xenomai" group, I mean this is only a
template in some rule file to illustrate the fact that one could
actually assign rt privileges to a user group, instead of running apps
as a sudoer. That could be any group you are willing to mention in the
xenomai.allowed_group kernel parameter on the kernel command line, or no
group at all. This is a matter of local installation.

> 
> Changing the permissions manually solved it. It's something about the packaging
> or the library?
> 

This is not a library issue.

> 
>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>> Init memory pool returns 1808 bytes
>>> Running after ...
>>> mem=0x7f2e146318e0, alloc_size=8192
>>> Init memory pool returns 1808 bytes
>>> Running after ...
>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
> 
>>
>> Not being able to open rtser0 is yet another kind of problem: the uart
>> driver is not up and running, so the devices were not created. crosslink
>> definitely needs such driver.
> 
> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
> 

Any RTDM driver from kernel/drivers/serial, depending on your platform.

> Also, /dev/cpu_dma_latency should not belongs to xenomai group?
> 

This is not a Xenomai resource, this one is created by the regular
kernel. Assuming you refer to cyclictest, I don't think this code can
run without root privileges. cyclictest is actually one of the official
test from the preempt-rt testsuite, which also builds and runs over Cobalt.

-- 
Philippe.

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Leopold Palomo-Avellaneda]

On 24/11/17 11:55, Philippe Gerum wrote:
> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>> Hi (again)
>>
>> running cross-link I got that:
>>
>>>> with my user
>>>>
>>>> ./cross-link
>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>> Init memory pool returns 1808 bytes
>>>> Running after ...
>>>> sysregd:
>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>> Permission denied
>>
>> ....
>>
>>
>> the permissions are:
>> $ ls -la /var/run/xenomai/
>> total 0
>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>
>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
> 
> There is no such official "Xenomai" group, I mean this is only a
> template in some rule file to illustrate the fact that one could
> actually assign rt privileges to a user group, instead of running apps
> as a sudoer. That could be any group you are willing to mention in the
> xenomai.allowed_group kernel parameter on the kernel command line, or no
> group at all. This is a matter of local installation.

Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
So, the packaging (installation should solve it).

>>
>> Changing the permissions manually solved it. It's something about the packaging
>> or the library?
>>
> 
> This is not a library issue.

Ok, mine. Packaging problem.

>>
>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>> Init memory pool returns 1808 bytes
>>>> Running after ...
>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>> Init memory pool returns 1808 bytes
>>>> Running after ...
>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>
>>>
>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>> driver is not up and running, so the devices were not created. crosslink
>>> definitely needs such driver.
>>
>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>
> 
> Any RTDM driver from kernel/drivers/serial, depending on your platform.

Well, I have /dev/rtdm/* entries but not that one. Is this normal?

>> Also, /dev/cpu_dma_latency should not belongs to xenomai group?
>>
> 
> This is not a Xenomai resource, this one is created by the regular
> kernel. Assuming you refer to cyclictest, I don't think this code can
> run without root privileges. cyclictest is actually one of the official
> test from the preempt-rt testsuite, which also builds and runs over Cobalt.
> 
Ok

Thanks,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Philippe Gerum]

On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
> On 24/11/17 11:55, Philippe Gerum wrote:
>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>> Hi (again)
>>>
>>> running cross-link I got that:
>>>
>>>>> with my user
>>>>>
>>>>> ./cross-link
>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>> Init memory pool returns 1808 bytes
>>>>> Running after ...
>>>>> sysregd:
>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>> Permission denied
>>>
>>> ....
>>>
>>>
>>> the permissions are:
>>> $ ls -la /var/run/xenomai/
>>> total 0
>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>
>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>
>> There is no such official "Xenomai" group, I mean this is only a
>> template in some rule file to illustrate the fact that one could
>> actually assign rt privileges to a user group, instead of running apps
>> as a sudoer. That could be any group you are willing to mention in the
>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>> group at all. This is a matter of local installation.
> 
> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
> So, the packaging (installation should solve it).
> 
>>>
>>> Changing the permissions manually solved it. It's something about the packaging
>>> or the library?
>>>
>>
>> This is not a library issue.
> 
> Ok, mine. Packaging problem.
> 
>>>
>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>> Init memory pool returns 1808 bytes
>>>>> Running after ...
>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>> Init memory pool returns 1808 bytes
>>>>> Running after ...
>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>
>>>>
>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>> driver is not up and running, so the devices were not created. crosslink
>>>> definitely needs such driver.
>>>
>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>
>>
>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
> 
> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
> 

Do you have any RTDM-based serial driver enabled in Kconfig?

-- 
Philippe.

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Leopold Palomo-Avellaneda]

On 24/11/17 13:04, Philippe Gerum wrote:
> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>> On 24/11/17 11:55, Philippe Gerum wrote:
>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>> Hi (again)
>>>>
>>>> running cross-link I got that:
>>>>
>>>>>> with my user
>>>>>>
>>>>>> ./cross-link
>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>> Init memory pool returns 1808 bytes
>>>>>> Running after ...
>>>>>> sysregd:
>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>> Permission denied
>>>>
>>>> ....
>>>>
>>>>
>>>> the permissions are:
>>>> $ ls -la /var/run/xenomai/
>>>> total 0
>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>
>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>
>>> There is no such official "Xenomai" group, I mean this is only a
>>> template in some rule file to illustrate the fact that one could
>>> actually assign rt privileges to a user group, instead of running apps
>>> as a sudoer. That could be any group you are willing to mention in the
>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>> group at all. This is a matter of local installation.
>>
>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>> So, the packaging (installation should solve it).
>>
>>>>
>>>> Changing the permissions manually solved it. It's something about the packaging
>>>> or the library?
>>>>
>>>
>>> This is not a library issue.
>>
>> Ok, mine. Packaging problem.
>>
>>>>
>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>> Init memory pool returns 1808 bytes
>>>>>> Running after ...
>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>> Init memory pool returns 1808 bytes
>>>>>> Running after ...
>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>
>>>>>
>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>> definitely needs such driver.
>>>>
>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>
>>>
>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>
>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>
> 
> Do you have any RTDM-based serial driver enabled in Kconfig?
> 

xeno_16550A

I have all modules that I can.

<M> 16550A UART driver
                              Hardware access mode (Any access mode)  ---> (X)
Any access mode

[*] PCI board support
                           [*]   Moxa PCI boards

CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
CONFIG_XENO_DRIVERS_AUTOTUNE=m

#
# Serial drivers
#
CONFIG_XENO_DRIVERS_16550A=m
# CONFIG_XENO_DRIVERS_16550A_PIO is not set
# CONFIG_XENO_DRIVERS_16550A_MMIO is not set
CONFIG_XENO_DRIVERS_16550A_ANY=y
CONFIG_XENO_DRIVERS_16550A_PCI=y
CONFIG_XENO_DRIVERS_16550A_PCI_MOXA=y






-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Philippe Gerum]

On 11/24/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
> On 24/11/17 13:04, Philippe Gerum wrote:
>> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>>> On 24/11/17 11:55, Philippe Gerum wrote:
>>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>>> Hi (again)
>>>>>
>>>>> running cross-link I got that:
>>>>>
>>>>>>> with my user
>>>>>>>
>>>>>>> ./cross-link
>>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>>> Init memory pool returns 1808 bytes
>>>>>>> Running after ...
>>>>>>> sysregd:
>>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>>> Permission denied
>>>>>
>>>>> ....
>>>>>
>>>>>
>>>>> the permissions are:
>>>>> $ ls -la /var/run/xenomai/
>>>>> total 0
>>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>>
>>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>>
>>>> There is no such official "Xenomai" group, I mean this is only a
>>>> template in some rule file to illustrate the fact that one could
>>>> actually assign rt privileges to a user group, instead of running apps
>>>> as a sudoer. That could be any group you are willing to mention in the
>>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>>> group at all. This is a matter of local installation.
>>>
>>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>>> So, the packaging (installation should solve it).
>>>
>>>>>
>>>>> Changing the permissions manually solved it. It's something about the packaging
>>>>> or the library?
>>>>>
>>>>
>>>> This is not a library issue.
>>>
>>> Ok, mine. Packaging problem.
>>>
>>>>>
>>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>>> Init memory pool returns 1808 bytes
>>>>>>> Running after ...
>>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>>> Init memory pool returns 1808 bytes
>>>>>>> Running after ...
>>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>>
>>>>>>
>>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>>> definitely needs such driver.
>>>>>
>>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>>
>>>>
>>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>>
>>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>>
>>
>> Do you have any RTDM-based serial driver enabled in Kconfig?
>>
> 
> xeno_16550A
> 
> I have all modules that I can.
> 
> <M> 16550A UART driver
>                               Hardware access mode (Any access mode)  ---> (X)
> Any access mode
> 
> [*] PCI board support
>                            [*]   Moxa PCI boards
> 
> CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
> CONFIG_XENO_DRIVERS_AUTOTUNE=m
> 
> #
> # Serial drivers
> #
> CONFIG_XENO_DRIVERS_16550A=m

missing modprobe?

-- 
Philippe.

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Leopold Palomo-Avellaneda]

On 24/11/17 13:22, Philippe Gerum wrote:
> On 11/24/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>> On 24/11/17 13:04, Philippe Gerum wrote:
>>> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>>>> On 24/11/17 11:55, Philippe Gerum wrote:
>>>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>>>> Hi (again)
>>>>>>
>>>>>> running cross-link I got that:
>>>>>>
>>>>>>>> with my user
>>>>>>>>
>>>>>>>> ./cross-link
>>>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>> Running after ...
>>>>>>>> sysregd:
>>>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>>>> Permission denied
>>>>>>
>>>>>> ....
>>>>>>
>>>>>>
>>>>>> the permissions are:
>>>>>> $ ls -la /var/run/xenomai/
>>>>>> total 0
>>>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>>>
>>>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>>>
>>>>> There is no such official "Xenomai" group, I mean this is only a
>>>>> template in some rule file to illustrate the fact that one could
>>>>> actually assign rt privileges to a user group, instead of running apps
>>>>> as a sudoer. That could be any group you are willing to mention in the
>>>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>>>> group at all. This is a matter of local installation.
>>>>
>>>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>>>> So, the packaging (installation should solve it).
>>>>
>>>>>>
>>>>>> Changing the permissions manually solved it. It's something about the packaging
>>>>>> or the library?
>>>>>>
>>>>>
>>>>> This is not a library issue.
>>>>
>>>> Ok, mine. Packaging problem.
>>>>
>>>>>>
>>>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>> Running after ...
>>>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>> Running after ...
>>>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>>>
>>>>>>>
>>>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>>>> definitely needs such driver.
>>>>>>
>>>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>>>
>>>>>
>>>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>>>
>>>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>>>
>>>
>>> Do you have any RTDM-based serial driver enabled in Kconfig?
>>>
>>
>> xeno_16550A
>>
>> I have all modules that I can.
>>
>> <M> 16550A UART driver
>>                               Hardware access mode (Any access mode)  ---> (X)
>> Any access mode
>>
>> [*] PCI board support
>>                            [*]   Moxa PCI boards
>>
>> CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
>> CONFIG_XENO_DRIVERS_AUTOTUNE=m
>>
>> #
>> # Serial drivers
>> #
>> CONFIG_XENO_DRIVERS_16550A=m
> 
> missing modprobe?
> 

$ lsmod | grep xeno
xeno_16550A            28672  0
xeno_autotune          24576  0
xeno_analogy           57344  0
xeno_rtdmtest          16384  0
xeno_udd               16384  0
xeno_switchtest        20480  0
xeno_rtipc             49152  0
xeno_can_peak_pci      16384  0
xeno_can_sja1000       20480  1 xeno_can_peak_pci
xeno_can               32768  2 xeno_can_peak_pci,xeno_can_sja1000



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Philippe Gerum]

On 11/24/2017 01:24 PM, Leopold Palomo-Avellaneda wrote:
> On 24/11/17 13:22, Philippe Gerum wrote:
>> On 11/24/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>> On 24/11/17 13:04, Philippe Gerum wrote:
>>>> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>>>>> On 24/11/17 11:55, Philippe Gerum wrote:
>>>>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>>>>> Hi (again)
>>>>>>>
>>>>>>> running cross-link I got that:
>>>>>>>
>>>>>>>>> with my user
>>>>>>>>>
>>>>>>>>> ./cross-link
>>>>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>> Running after ...
>>>>>>>>> sysregd:
>>>>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>>>>> Permission denied
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>>
>>>>>>> the permissions are:
>>>>>>> $ ls -la /var/run/xenomai/
>>>>>>> total 0
>>>>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>>>>
>>>>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>>>>
>>>>>> There is no such official "Xenomai" group, I mean this is only a
>>>>>> template in some rule file to illustrate the fact that one could
>>>>>> actually assign rt privileges to a user group, instead of running apps
>>>>>> as a sudoer. That could be any group you are willing to mention in the
>>>>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>>>>> group at all. This is a matter of local installation.
>>>>>
>>>>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>>>>> So, the packaging (installation should solve it).
>>>>>
>>>>>>>
>>>>>>> Changing the permissions manually solved it. It's something about the packaging
>>>>>>> or the library?
>>>>>>>
>>>>>>
>>>>>> This is not a library issue.
>>>>>
>>>>> Ok, mine. Packaging problem.
>>>>>
>>>>>>>
>>>>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>> Running after ...
>>>>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>> Running after ...
>>>>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>>>>
>>>>>>>>
>>>>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>>>>> definitely needs such driver.
>>>>>>>
>>>>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>>>>
>>>>>>
>>>>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>>>>
>>>>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>>>>
>>>>
>>>> Do you have any RTDM-based serial driver enabled in Kconfig?
>>>>
>>>
>>> xeno_16550A
>>>
>>> I have all modules that I can.
>>>
>>> <M> 16550A UART driver
>>>                               Hardware access mode (Any access mode)  ---> (X)
>>> Any access mode
>>>
>>> [*] PCI board support
>>>                            [*]   Moxa PCI boards
>>>
>>> CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
>>> CONFIG_XENO_DRIVERS_AUTOTUNE=m
>>>
>>> #
>>> # Serial drivers
>>> #
>>> CONFIG_XENO_DRIVERS_16550A=m
>>
>> missing modprobe?
>>
> 
> $ lsmod | grep xeno
> xeno_16550A            28672  0
> xeno_autotune          24576  0
> xeno_analogy           57344  0
> xeno_rtdmtest          16384  0
> xeno_udd               16384  0
> xeno_switchtest        20480  0
> xeno_rtipc             49152  0
> xeno_can_peak_pci      16384  0
> xeno_can_sja1000       20480  1 xeno_can_peak_pci
> xeno_can               32768  2 xeno_can_peak_pci,xeno_can_sja1000
> 
> 
> 

It looks like the driver was not given the proper parameters at load up,
specifically the io= or mem= information.

http://xenomai.org/serial-16550a-driver/ may help.

-- 
Philippe.

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Leopold Palomo-Avellaneda]

On 24/11/17 15:21, Philippe Gerum wrote:
> On 11/24/2017 01:24 PM, Leopold Palomo-Avellaneda wrote:
>> On 24/11/17 13:22, Philippe Gerum wrote:
>>> On 11/24/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>> On 24/11/17 13:04, Philippe Gerum wrote:
>>>>> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>>>>>> On 24/11/17 11:55, Philippe Gerum wrote:
>>>>>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>>>>>> Hi (again)
>>>>>>>>
>>>>>>>> running cross-link I got that:
>>>>>>>>
>>>>>>>>>> with my user
>>>>>>>>>>
>>>>>>>>>> ./cross-link
>>>>>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>> Running after ...
>>>>>>>>>> sysregd:
>>>>>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>>>>>> Permission denied
>>>>>>>>
>>>>>>>> ....
>>>>>>>>
>>>>>>>>
>>>>>>>> the permissions are:
>>>>>>>> $ ls -la /var/run/xenomai/
>>>>>>>> total 0
>>>>>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>>>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>>>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>>>>>
>>>>>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>>>>>
>>>>>>> There is no such official "Xenomai" group, I mean this is only a
>>>>>>> template in some rule file to illustrate the fact that one could
>>>>>>> actually assign rt privileges to a user group, instead of running apps
>>>>>>> as a sudoer. That could be any group you are willing to mention in the
>>>>>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>>>>>> group at all. This is a matter of local installation.
>>>>>>
>>>>>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>>>>>> So, the packaging (installation should solve it).
>>>>>>
>>>>>>>>
>>>>>>>> Changing the permissions manually solved it. It's something about the packaging
>>>>>>>> or the library?
>>>>>>>>
>>>>>>>
>>>>>>> This is not a library issue.
>>>>>>
>>>>>> Ok, mine. Packaging problem.
>>>>>>
>>>>>>>>
>>>>>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>> Running after ...
>>>>>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>> Running after ...
>>>>>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>>>>>> definitely needs such driver.
>>>>>>>>
>>>>>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>>>>>
>>>>>>>
>>>>>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>>>>>
>>>>>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>>>>>
>>>>>
>>>>> Do you have any RTDM-based serial driver enabled in Kconfig?
>>>>>
>>>>
>>>> xeno_16550A
>>>>
>>>> I have all modules that I can.
>>>>
>>>> <M> 16550A UART driver
>>>>                               Hardware access mode (Any access mode)  ---> (X)
>>>> Any access mode
>>>>
>>>> [*] PCI board support
>>>>                            [*]   Moxa PCI boards
>>>>
>>>> CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
>>>> CONFIG_XENO_DRIVERS_AUTOTUNE=m
>>>>
>>>> #
>>>> # Serial drivers
>>>> #
>>>> CONFIG_XENO_DRIVERS_16550A=m
>>>
>>> missing modprobe?
>>>
>>
>> $ lsmod | grep xeno
>> xeno_16550A            28672  0
>> xeno_autotune          24576  0
>> xeno_analogy           57344  0
>> xeno_rtdmtest          16384  0
>> xeno_udd               16384  0
>> xeno_switchtest        20480  0
>> xeno_rtipc             49152  0
>> xeno_can_peak_pci      16384  0
>> xeno_can_sja1000       20480  1 xeno_can_peak_pci
>> xeno_can               32768  2 xeno_can_peak_pci,xeno_can_sja1000
>>
>>
>>
> 
> It looks like the driver was not given the proper parameters at load up,
> specifically the io= or mem= information.
> 
> http://xenomai.org/serial-16550a-driver/ may help.
> 

ok,

I have followed this page and got:

DMAR: DRHD: handling fault status reg 2
[   90.453076] DMAR: [INTR-REMAP] Request device [f0:1f.0] fault index 0 [fault
reason 37] Blocked a compatibility format interrupt request
root@bmm3:~# modprobe xeno_16550A io=0xf0a0 irq=19


Anyway, next week I hope to be more lucky. Thanks for all,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager)

[Philippe Gerum]

On 11/24/2017 03:38 PM, Leopold Palomo-Avellaneda wrote:
> On 24/11/17 15:21, Philippe Gerum wrote:
>> On 11/24/2017 01:24 PM, Leopold Palomo-Avellaneda wrote:
>>> On 24/11/17 13:22, Philippe Gerum wrote:
>>>> On 11/24/2017 01:10 PM, Leopold Palomo-Avellaneda wrote:
>>>>> On 24/11/17 13:04, Philippe Gerum wrote:
>>>>>> On 11/24/2017 01:01 PM, Leopold Palomo-Avellaneda wrote:
>>>>>>> On 24/11/17 11:55, Philippe Gerum wrote:
>>>>>>>> On 11/24/2017 11:34 AM, Leopold Palomo-Avellaneda wrote:
>>>>>>>>> Hi (again)
>>>>>>>>>
>>>>>>>>> running cross-link I got that:
>>>>>>>>>
>>>>>>>>>>> with my user
>>>>>>>>>>>
>>>>>>>>>>> ./cross-link
>>>>>>>>>>> mem=0x7f0d630488e0, alloc_size=8192
>>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>>> Running after ...
>>>>>>>>>>> sysregd:
>>>>>>>>>>> create_directory_recursive("/var/run/xenomai/leopold.palomo/anon@19479"):
>>>>>>>>>>> Permission denied
>>>>>>>>>
>>>>>>>>> ....
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the permissions are:
>>>>>>>>> $ ls -la /var/run/xenomai/
>>>>>>>>> total 0
>>>>>>>>> drwxr-xr-x  3 root root  60 nov 23 16:03 .
>>>>>>>>> drwxr-xr-x 24 root root 860 nov 24 11:12 ..
>>>>>>>>> drwxr-xr-x  2 root root  40 nov 24 11:12 root
>>>>>>>>>
>>>>>>>>> so, IMHO this folder should belongs to xenomai group and permisions g+rw. Right?
>>>>>>>>
>>>>>>>> There is no such official "Xenomai" group, I mean this is only a
>>>>>>>> template in some rule file to illustrate the fact that one could
>>>>>>>> actually assign rt privileges to a user group, instead of running apps
>>>>>>>> as a sudoer. That could be any group you are willing to mention in the
>>>>>>>> xenomai.allowed_group kernel parameter on the kernel command line, or no
>>>>>>>> group at all. This is a matter of local installation.
>>>>>>>
>>>>>>> Ok, the debian package creates it. I have xenomai.allowed_group=113 in the grub.
>>>>>>> So, the packaging (installation should solve it).
>>>>>>>
>>>>>>>>>
>>>>>>>>> Changing the permissions manually solved it. It's something about the packaging
>>>>>>>>> or the library?
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is not a library issue.
>>>>>>>
>>>>>>> Ok, mine. Packaging problem.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> leopold.palomo@bmm3 ~/xenomai/xenomai-3.0.6/system/demo$ sudo ./cross-link
>>>>>>>>>>> mem=0x7fc9e73f88e0, alloc_size=8192
>>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>>> Running after ...
>>>>>>>>>>> mem=0x7f2e146318e0, alloc_size=8192
>>>>>>>>>>> Init memory pool returns 1808 bytes
>>>>>>>>>>> Running after ...
>>>>>>>>>>> main : can't open /dev/rtdm/rtser0 (write), No such file or directory
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not being able to open rtser0 is yet another kind of problem: the uart
>>>>>>>>>> driver is not up and running, so the devices were not created. crosslink
>>>>>>>>>> definitely needs such driver.
>>>>>>>>>
>>>>>>>>> Yes, I don't have rtser0 entry in /dev/rtdm/. Who does create it?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Any RTDM driver from kernel/drivers/serial, depending on your platform.
>>>>>>>
>>>>>>> Well, I have /dev/rtdm/* entries but not that one. Is this normal?
>>>>>>>
>>>>>>
>>>>>> Do you have any RTDM-based serial driver enabled in Kconfig?
>>>>>>
>>>>>
>>>>> xeno_16550A
>>>>>
>>>>> I have all modules that I can.
>>>>>
>>>>> <M> 16550A UART driver
>>>>>                               Hardware access mode (Any access mode)  ---> (X)
>>>>> Any access mode
>>>>>
>>>>> [*] PCI board support
>>>>>                            [*]   Moxa PCI boards
>>>>>
>>>>> CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
>>>>> CONFIG_XENO_DRIVERS_AUTOTUNE=m
>>>>>
>>>>> #
>>>>> # Serial drivers
>>>>> #
>>>>> CONFIG_XENO_DRIVERS_16550A=m
>>>>
>>>> missing modprobe?
>>>>
>>>
>>> $ lsmod | grep xeno
>>> xeno_16550A            28672  0
>>> xeno_autotune          24576  0
>>> xeno_analogy           57344  0
>>> xeno_rtdmtest          16384  0
>>> xeno_udd               16384  0
>>> xeno_switchtest        20480  0
>>> xeno_rtipc             49152  0
>>> xeno_can_peak_pci      16384  0
>>> xeno_can_sja1000       20480  1 xeno_can_peak_pci
>>> xeno_can               32768  2 xeno_can_peak_pci,xeno_can_sja1000
>>>
>>>
>>>
>>
>> It looks like the driver was not given the proper parameters at load up,
>> specifically the io= or mem= information.
>>
>> http://xenomai.org/serial-16550a-driver/ may help.
>>
> 
> ok,
> 
> I have followed this page and got:
> 
> DMAR: DRHD: handling fault status reg 2
> [   90.453076] DMAR: [INTR-REMAP] Request device [f0:1f.0] fault index 0 [fault
> reason 37] Blocked a compatibility format interrupt request

It looks like there is a device on the PCI bus issuing interrupts with a
wrong format, specifically a compat format IRQ despite your kernel
config enables interrupt remapping. This is reported by a fault
interrupt. lspci should tell you which device is mentioned in the fault
report (f0:1f.0).

lspci -v may help finding the offender. passing iommu=debug on the
kernel command line should dump some useful information regarding the
DMA remapping hardware too.

I don't think this issue could be related to Xenomai though, since the
latter is not involved in the setup process of neither the IOMMU nor the
PCI devices. Enabling that specific PCI device in the RTDM serial driver
is likely to reveal an earlier misconfiguration though.

-- 
Philippe.