* [Xenomai] Cannot initialize TLSF memory manager @ 2017-11-23 12:10 Leopold Palomo-Avellaneda 2017-11-23 12:22 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-23 12:10 UTC (permalink / raw) To: Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 12:10 [Xenomai] Cannot initialize TLSF memory manager Leopold Palomo-Avellaneda @ 2017-11-23 12:22 ` Philippe Gerum 2017-11-23 14:58 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-23 12:22 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 12:22 ` Philippe Gerum @ 2017-11-23 14:58 ` Leopold Palomo-Avellaneda 2017-11-23 15:04 ` Philippe Gerum 2017-11-23 15:04 ` [Xenomai] Cannot initialize TLSF memory manager Leopold Palomo-Avellaneda 0 siblings, 2 replies; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-23 14:58 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 14:58 ` Leopold Palomo-Avellaneda @ 2017-11-23 15:04 ` Philippe Gerum 2017-11-23 15:08 ` Leopold Palomo-Avellaneda 2017-11-23 15:04 ` [Xenomai] Cannot initialize TLSF memory manager Leopold Palomo-Avellaneda 1 sibling, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-23 15:04 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 15:04 ` Philippe Gerum @ 2017-11-23 15:08 ` Leopold Palomo-Avellaneda 2017-11-23 15:12 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-23 15:08 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 15:08 ` Leopold Palomo-Avellaneda @ 2017-11-23 15:12 ` Philippe Gerum 2017-11-23 15:15 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-23 15:12 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 15:12 ` Philippe Gerum @ 2017-11-23 15:15 ` Leopold Palomo-Avellaneda 2017-11-23 15:29 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-23 15:15 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 15:15 ` Leopold Palomo-Avellaneda @ 2017-11-23 15:29 ` Philippe Gerum 2017-11-24 10:34 ` [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-23 15:29 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-23 15:29 ` Philippe Gerum @ 2017-11-24 10:34 ` Leopold Palomo-Avellaneda 2017-11-24 10:55 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-24 10:34 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 10:34 ` [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) Leopold Palomo-Avellaneda @ 2017-11-24 10:55 ` Philippe Gerum 2017-11-24 12:01 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-24 10:55 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 10:55 ` Philippe Gerum @ 2017-11-24 12:01 ` Leopold Palomo-Avellaneda 2017-11-24 12:04 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-24 12:01 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 12:01 ` Leopold Palomo-Avellaneda @ 2017-11-24 12:04 ` Philippe Gerum 2017-11-24 12:10 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-24 12:04 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 12:04 ` Philippe Gerum @ 2017-11-24 12:10 ` Leopold Palomo-Avellaneda 2017-11-24 12:22 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-24 12:10 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 12:10 ` Leopold Palomo-Avellaneda @ 2017-11-24 12:22 ` Philippe Gerum 2017-11-24 12:24 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-24 12:22 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 12:22 ` Philippe Gerum @ 2017-11-24 12:24 ` Leopold Palomo-Avellaneda 2017-11-24 14:21 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-24 12:24 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 12:24 ` Leopold Palomo-Avellaneda @ 2017-11-24 14:21 ` Philippe Gerum 2017-11-24 14:38 ` Leopold Palomo-Avellaneda 0 siblings, 1 reply; 19+ messages in thread From: Philippe Gerum @ 2017-11-24 14:21 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 14:21 ` Philippe Gerum @ 2017-11-24 14:38 ` Leopold Palomo-Avellaneda 2017-11-25 20:27 ` Philippe Gerum 0 siblings, 1 reply; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-24 14:38 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) 2017-11-24 14:38 ` Leopold Palomo-Avellaneda @ 2017-11-25 20:27 ` Philippe Gerum 0 siblings, 0 replies; 19+ messages in thread From: Philippe Gerum @ 2017-11-25 20:27 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai] Cannot initialize TLSF memory manager 2017-11-23 14:58 ` Leopold Palomo-Avellaneda 2017-11-23 15:04 ` Philippe Gerum @ 2017-11-23 15:04 ` Leopold Palomo-Avellaneda 1 sibling, 0 replies; 19+ messages in thread From: Leopold Palomo-Avellaneda @ 2017-11-23 15:04 UTC (permalink / raw) To: Philippe Gerum, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-11-25 20:27 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-23 12:10 [Xenomai] Cannot initialize TLSF memory manager Leopold Palomo-Avellaneda 2017-11-23 12:22 ` Philippe Gerum 2017-11-23 14:58 ` Leopold Palomo-Avellaneda 2017-11-23 15:04 ` Philippe Gerum 2017-11-23 15:08 ` Leopold Palomo-Avellaneda 2017-11-23 15:12 ` Philippe Gerum 2017-11-23 15:15 ` Leopold Palomo-Avellaneda 2017-11-23 15:29 ` Philippe Gerum 2017-11-24 10:34 ` [Xenomai] Testing 3.0.6 (Was Re: Cannot initialize TLSF memory manager) Leopold Palomo-Avellaneda 2017-11-24 10:55 ` Philippe Gerum 2017-11-24 12:01 ` Leopold Palomo-Avellaneda 2017-11-24 12:04 ` Philippe Gerum 2017-11-24 12:10 ` Leopold Palomo-Avellaneda 2017-11-24 12:22 ` Philippe Gerum 2017-11-24 12:24 ` Leopold Palomo-Avellaneda 2017-11-24 14:21 ` Philippe Gerum 2017-11-24 14:38 ` Leopold Palomo-Avellaneda 2017-11-25 20:27 ` Philippe Gerum 2017-11-23 15:04 ` [Xenomai] Cannot initialize TLSF memory manager Leopold Palomo-Avellaneda
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.