[Xenomai] Gpio-core question

[Greg Gallagher]

Hi,
  I'm finishing up my work on a patch to add a RTDM gpio driver for
the zynq-7000 platform.  I ran into a situation where I needed to call
gpio_request in gpio-core because the zynq gpio driver uses the
gpio_request function to enable the gpio pins on the board.
A side effect that I found when testing is that the driver will fail to
load
if another application has exported a gpio pin via sysfs and likewise sysfs
won't allow anyone to export gpio pins once the rtdm gpio driver has been
loaded.
My implementation calls gpio_request on each pin as they are  registered
under /dev/rtdm.
I'm not sure if the above is an issue or not, if the RTDM driver has
claimed the
gpio pins then I think it would make sense for them not to be accessible by
applications
via sysfs.  If my assumption is not correct then maybe one option could be
to only call gpio_request on each pin as need, maybe via ioctl?

Any guidance would be appreciated,

Greg
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Steven Seeger]

> Hi Steven,
> 
> I have remote access to many ppc boards and could help here. This said
> 85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
> - maybe adding mpc52xx would be good, I have one here. I don't see much
> traction these days for Xenomai over ppc64, so I'm not even sure whether
> this port is still relevant.

I have never used ppc64 so I would take some time coming up to speed with it 
(and would need access to a board.) I am sure you can tell from all our 
private emails over the last couple years that I wouldn't have a problem with 
ppc32. 

I am unsure how remote access to boards works especially at this level of 
work. Is there some way to power on and off if needed or do they depend on a 
watchdog? We can discuss this offline.

Steven


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 09:36 PM, Philippe Gerum wrote:

On 11/23/2017 01:38 PM, Jorge Ramirez wrote:

Xenomai also lacks an IRC channel which makes things way too quiet for a
small size community (in the case of ffmpeg for instance IRC is where
most if not all the discussions happen). IRC is - and should be for
Xenomai- a good place to ask for help and direction. So I vote for
having one.


IRC may be intrusive to some people, as it is by design preempting one's
attention unlike e-mail. This might work if a sufficient number of
people is actually willing to help on the channel though. Maybe.



IRC notifications can be ignored just like any others (you can just 
listen to certain nicks or keys as most users do)
There are pretty decent tools these days. (as an example I follow ten to 
twenty channels and it is not that bad).


I understand the point of not having a sufficient number of people 
willing - maybe capable is a better word?- to help (core knowledge today 
is pretty much concentrated in yourself which is issue #1).
But the way I see it an IRC channel should be a step towards removing 
that issue - those that tend/need to spend more time working with 
Xenomai (maybe developing a product) will end up driving the channel. 
And that is something that I think is needed.


And clearly IRC doesnt replace mailing lists: these are different tools 
for difference use cases.


I think the tools that we provide will end up shaping the community that 
we will have.
To me, not having a channel is an issue. You kind of pointed out that 
the channel -at least at the beginning- will probably just be many 
questions and little answers.


But maybe not? there are many products out there using Xenomai so who 
knows.
















___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Philippe Gerum]

On 11/23/2017 01:38 PM, Jorge Ramirez wrote:
> Xenomai also lacks an IRC channel which makes things way too quiet for a
> small size community (in the case of ffmpeg for instance IRC is where
> most if not all the discussions happen). IRC is - and should be for
> Xenomai- a good place to ask for help and direction. So I vote for
> having one.
> 

IRC may be intrusive to some people, as it is by design preempting one's
attention unlike e-mail. This might work if a sufficient number of
people is actually willing to help on the channel though. Maybe.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Lennart Sorensen]

On Thu, Nov 23, 2017 at 01:38:03PM +0100, Jorge Ramirez wrote:
> In the past year alone I have been contributing to uboot (as board
> maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 support),
> zephyr (multiple drivers), the linux kernel (some fixes), AOSP (fixes) and a
> few others. So I have gained certain exposure to a number of workflows.
> 
> with this in mind I think the Zephyr workflow would suit Xenomai nicely.

I personally like the linux kernel workflow where everything is through
a mailing list and patches are reviewed before they go in.  I am not
sure that workflow would work for xenomai, but I do like it.

> It spins around Github and integrates with Shippable - this means that on
> each pull request, we can trigger a full rebuild and run sanity and maybe
> even performance tests before any code review can begin; the subsystem
> maintainer/s then can review the pull request adding comments on the code as
> it moves along.

I am not sure build tests are that useful given the number of different
platforms the code runs on.  Which one do you build test for?

> Xenomai also lacks an IRC channel which makes things way too quiet for a
> small size community (in the case of ffmpeg for instance IRC is where most
> if not all the discussions happen). IRC is - and should be for Xenomai- a
> good place to ask for help and direction. So I vote for having one.

IRC is useless when the community is small and spread across timezones.
At least with the mailing list people will see the question and can
answer it when it hits their timezone.  IRC isn't helpful when no one
is there to read your question when you write it.  And good luck trying
to convey anything complex in an IRC conversation.  Want to try sending
source code patches through IRC for discussion?

I check my email daily.  I don't check random websites daily to check
the forums for project x, y and z each with a different interface.
Too much work.

> To sum up, given the low rate of patches that Xenomai handles and given the
> need push back on performance degradation I strongly believe that the
> Zephyr's workflow would work for us. The way performance ramifications are
> maintained today is pretty much living in Philippe's and possibly Jan's
> head: I think we should move from intuition to explicit measurable data when
> merging PRs (ie, establishing a multi-board CI loop)

-- 
Len Sorensen

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> On 2017-11-22 16:32, Philippe Gerum wrote:
>>
>> Hi Kendall,
>>
>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>> Hi Philippe,
>>>
>>> Is there an online bug tracking and feature request database? This would be 
>>> a useful way to distribute work and to sync up contributors. I think the 
>>> kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many 
>>> others.
>>>
>>> I'd like to contribute in some way. I've been having a lot of fun as a 
>>> Xenomai user.
>>>
>> We don't have that unfortunately. As suggested by several posters,
>> moving to a git-based, integrated development framework such as gitlab
>> or github would bring in that feature, and others we need too (CI).
>>
>> I have no issue moving the project from the current git server at
>> xenomai.org to any of these environments.
>>
> 
> If it helps the community to grow, I would not refuse such a move. But I
> would like to raise some concerns about platforms like github or gitlab
> that we must be aware of:
> 
> - lacking integration with email-based workflows (while kernel
>   development tends to be based on that...)
> 
> - risk of decoupling communities when parts of the discussions happen on
>   tickets or PRs and parts in mailing list threads
> 
> Therefore, most projects I manage on github and in our internal gitlab
> have clear policies like "no emails, only tickets and PRs" or "no PRs,
> only patches on the mailing list". Even just using the issue tracker to
> keep some to-do list requires discipline to direct discussions
> consequently to a mailing list if that exists as well (and that usually
> does not work very well).
> 
> IOW: we need to be clear in what we want a platform for - and what not.
> 

Defining the process first may help, then we could certainly find a tool
that fits the requirement. AFAICT, reports from users and maintainers
mainly fall into these categories:

- perceived runtime bugs (confirmed or not)
- configuration, installation problems
- request for change, improvements

Reports about runtime bugs should be posted to mailing list first,
unless they have been directly observed by a subsystem maintainer. If
the issue is confirmed, it should be logged into the tracker by the
concerned subsystem maintainer. Many users report bugs which have
already been solved, the tracker should help making the solution visible
for closed issues, or maybe we'd need another way to bring up that
information to the attention of users.

Request for changes should translate into RFCs to the mailing list so
they can be discussed, last but not least to prevent duplicate effort
with potentially ongoing work. A detailed description of what is
needed/planned could then be published to a dedicated section of the web
site in free form; this would contribute to the general TODO list Greg
mentioned earlier.

Questions about configuration and installation can be efficiently dealt
with good documentation (TBD) and a mailing list.

To get this process working, I don't think we'd need more than a tracker
with write access to subsystem maintainers only (once we have some, that
is), and the existing mailing list, which should prevent crosstalk.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jan Kiszka]

On 2017-11-23 14:18, Jorge Ramirez wrote:
> On 11/23/2017 01:52 PM, Henning Schild wrote:
>> Am Thu, 23 Nov 2017 12:42:08 +0100
>> schrieb Philippe Gerum :
>>
>>> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
 On 2017-11-22 16:32, Philippe Gerum wrote:
> Hi Kendall,
>
> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>> Hi Philippe,
>>
>> Is there an online bug tracking and feature request database?
>> This would be a useful way to distribute work and to sync up
>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
>> Launchpad. No doubt there are many others.
>>
>> I'd like to contribute in some way. I've been having a lot of fun
>> as a Xenomai user.
> We don't have that unfortunately. As suggested by several posters,
> moving to a git-based, integrated development framework such as
> gitlab or github would bring in that feature, and others we need
> too (CI).
>
> I have no issue moving the project from the current git server at
> xenomai.org to any of these environments.
>   
 If it helps the community to grow, I would not refuse such a move.
 But I would like to raise some concerns about platforms like github
 or gitlab that we must be aware of:

 - lacking integration with email-based workflows (while kernel
    development tends to be based on that...)

 - risk of decoupling communities when parts of the discussions
 happen on tickets or PRs and parts in mailing list threads

 Therefore, most projects I manage on github and in our internal
 gitlab have clear policies like "no emails, only tickets and PRs"
 or "no PRs, only patches on the mailing list". Even just using the
 issue tracker to keep some to-do list requires discipline to direct
 discussions consequently to a mailing list if that exists as well
 (and that usually does not work very well).

 IOW: we need to be clear in what we want a platform for - and what
 not.
>>> Forking the original thread to get input from the list specifically
>>> regarding the idea of moving GIT services from xenomai.org to a public
>>> software development platform.
>>>
>>> As Jan mentioned, there is more than having GIT underneath, there are
>>> deep implications on the workflow, and it really depends on what we'd
>>> want from such platform. If you have any thought, recommendation,
>>> experience with those platforms in your daily work, it would be great
>>> to know your views.
>> Jan is absolutely right here. Before moving to github (or something
>> alike) you need to set groundrules for how to deal with PRs, issues and
>> all the stuff that you suddenly gain.
>>
>> I think Xenomai could benefit from issue tracking and CI, not sure
>> whether we need github for that.
> 
> issue tracking is not something that important IMO.
> I dont believe this is extensively used by any projects but mainly distros.
> 
>> The CI they offer is docker-based and
>> we would likely want something more powerful. But i guess you could
>> always use docker to remote control AWS or real hardware.
> 
> yes. there are a number of solutions that in fact do OTA and most of
> them use Docker to control real hardware.
> the industry seems to be going in that direction. I think Shippable
> should server our purpose.
> 
> for instance, check out this commit:
> https://github.com/zephyrproject-rtos/zephyr/pull/5134
> 
> and its shippable output
> https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console
> 

Shippable looks interesting. We are working internally with gitlab-ci
and for several public projects with Travis. But the free services are
usually nothing for "serious" workload like kernel builds because they
either lack powerful builders or have limits on the job length - or both
which doesn't make it better. For Jailhouse, I worked around that in
Travis by caching the required kernel build.

Do you know what limits exist in shippable?

> 
>> github sucks at routing mails. My github account is shared between my
>> work and personal stuff but i do not star/watch any work related
>> projects because i do not want the notifications in my personal inbox.
> 
> I agree that it sucks but I dont see why this should be an issue.
> Just dont rely on github emails (I personally tend to disable them, they
> are extremely annoying).
> 
> when I need to find out how any PR is progressing (every other day) I
> just connect to github.

It's a personal thing, but web UIs do not scale for me. I'm on way too
many platforms, and all suck at least a little bit in certain ways. But
then, when you then need to combine them to keep track, the problem
becomes serious because email do not work for most of them. Again, a
personal issue I just happen to share with many kernel hackers.

In the end, the platform we pick depends on the group of developers we
want to attract. If the majority of our key 

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
>>  

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 

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.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

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?

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

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?

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

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.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Strange scheduling behaviour

[Philippe Gerum]

On 11/23/2017 03:35 PM, Cédric Perles wrote:
>>> Hi,
>>>
>>> I’m working on an iMX6 based board with NXP kernel 4.1.15.
> 
>>> Vendor kernels for i.MX6 are creepy (another vowel comes to mind). A 
>>> recent mainline kernel is just fine if the SoC supports it. If not, 
>>> porting the SoC (and/or missing driver) to mainline is often much > 
>>> better and faster than enduring a truckload of bugs.
> 
>>> I would like to understand why latency max returned by cyclictest
>>> increases from 20µs to 100µs when dohell accesses to USB.
>>>
>>> Since i-pipe tracer refuses to work,
> 
>> Which means?
> 
> I sent a message on this subject 
> (https://xenomai.org/pipermail/xenomai/2017-November/037919.html).
> I don't know why but my kernel don't boot when ipipe tracer is activated.
> 
>>> I used ftrace to record cobalt,
>>> scheduling and irq events. Here is what I see on kernelshark:
>>>
>>> As expected, cyclictest has 1 xenomai thread per core (I can see them
>>> on
>>> /proc/xenomai/sched/threads) that wakes up periodically after a 200µs
>>> nanosleep.
>>>
>>> Sometimes, the wake up seems to be delayed (400µs instead of 200µs)
>>> because of an USB irq treatment followed by a call to usb-storage.
>>> Other times, the wake up seems to be delayed (400µs instead of 200µs)
>>> by a Linux call to ktimersoft, rcu and cat (see
>>> https://drive.google.com/file/d/18-B3WO2QH7PvBzJrt9tK5-TXvAkDxTPn/view
>>> ?usp
>>> =sharing)
>>>
> 
>> The textual trace shows no issue. 40us are spent suspending a Cobalt 
>> thread, which seems reasonable on i.MX6Q with ftrace enabled and the slow 
>> PL310 L2 outer cache you have there. I likely missed your point then.
> 
>>> Is it normal to delay a xenomai task wake up because of a Linux
>>> interrupt (I expected ipipe to act as a shield) ?
>>> How a simple Linux "cat" can delay a xenomai wake up ?
>>>
> 
>> For instance, if the Xenomai task in question dropped to secondary mode 
>> earlier because the app is wrong somehow, then some work queue kernel 
>> thread starts running funky driver code issuing usleep() to sync with the 
>> hw. The rt thread running in non-rt mode will have to wait until the 
>> driver stops busy-waiting for a bit to toggle, causing the next rt 
>> operation for that task to appear as badly delayed. > The point is, that 
>> Xenomai is not in charge when the delay appears.
> 
>> This case has been observed several times with MMC host and PCI host 
>> drivers on fsl kernels; I would not be surprised if that happened with 
>> other vendor-specific driver(s) too.
> 
> I agree, if the application dropped to secondary mode, it would explain the 
> trace. However, I don't think we drop to secondary.
> The application is the cyclictest included with xenomai tools to bench real 
> time performances through posix skin. I don't expect such application to 
> switch to secondary. Moreover, /proc/xenomai/sched/stat indicates no mode 
> switch (MSW is stuck to 1 for this thread).
> 
> I made another test and set cyclictest period to 400µs. In this case, the 
> wake up is sometime 800µs instead of 400µs. It's just like if 
> clock_nanosleep used by cyclictest missed some events.
> 

I see no correlation between the traces you sent and the behavior just
described though.

I don't know which pipeline code you have been using so far, we follow
mainline only. This said, some imx6 have the infamous C3STOP mode
enabled for the TWD, which may cause the main timer to be switched to a
general purpose timer, and the TWD to be temporarily stopped, which does
not cope well with the current Cobalt implementation.

You may want to check if the CPUIDLE framework is not getting in the way.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Strange scheduling behaviour

[Cédric Perles]

>> Hi,
>>
>> I’m working on an iMX6 based board with NXP kernel 4.1.15.

>> Vendor kernels for i.MX6 are creepy (another vowel comes to mind). A 
>> recent mainline kernel is just fine if the SoC supports it. If not, 
>> porting the SoC (and/or missing driver) to mainline is often much > 
>> better and faster than enduring a truckload of bugs.

>> I would like to understand why latency max returned by cyclictest
>> increases from 20µs to 100µs when dohell accesses to USB.
>>
>> Since i-pipe tracer refuses to work,

> Which means?

I sent a message on this subject 
(https://xenomai.org/pipermail/xenomai/2017-November/037919.html).
I don't know why but my kernel don't boot when ipipe tracer is activated.

>> I used ftrace to record cobalt,
>> scheduling and irq events. Here is what I see on kernelshark:
>>
>> As expected, cyclictest has 1 xenomai thread per core (I can see them
>> on
>> /proc/xenomai/sched/threads) that wakes up periodically after a 200µs
>> nanosleep.
>>
>> Sometimes, the wake up seems to be delayed (400µs instead of 200µs)
>> because of an USB irq treatment followed by a call to usb-storage.
>> Other times, the wake up seems to be delayed (400µs instead of 200µs)
>> by a Linux call to ktimersoft, rcu and cat (see
>> https://drive.google.com/file/d/18-B3WO2QH7PvBzJrt9tK5-TXvAkDxTPn/view
>> ?usp
>> =sharing)
>>

> The textual trace shows no issue. 40us are spent suspending a Cobalt 
> thread, which seems reasonable on i.MX6Q with ftrace enabled and the slow 
> PL310 L2 outer cache you have there. I likely missed your point then.

>> Is it normal to delay a xenomai task wake up because of a Linux
>> interrupt (I expected ipipe to act as a shield) ?
>> How a simple Linux "cat" can delay a xenomai wake up ?
>>

> For instance, if the Xenomai task in question dropped to secondary mode 
> earlier because the app is wrong somehow, then some work queue kernel 
> thread starts running funky driver code issuing usleep() to sync with the 
> hw. The rt thread running in non-rt mode will have to wait until the 
> driver stops busy-waiting for a bit to toggle, causing the next rt 
> operation for that task to appear as badly delayed. > The point is, that 
> Xenomai is not in charge when the delay appears.

> This case has been observed several times with MMC host and PCI host 
> drivers on fsl kernels; I would not be surprised if that happened with 
> other vendor-specific driver(s) too.

I agree, if the application dropped to secondary mode, it would explain the 
trace. However, I don't think we drop to secondary.
The application is the cyclictest included with xenomai tools to bench real 
time performances through posix skin. I don't expect such application to 
switch to secondary. Moreover, /proc/xenomai/sched/stat indicates no mode 
switch (MSW is stuck to 1 for this thread).

I made another test and set cyclictest period to 400µs. In this case, the 
wake up is sometime 800µs instead of 400µs. It's just like if 
clock_nanosleep used by cyclictest missed some events.

--
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Giulio Moro]

At Bela (bela.io) we use Xenomai on the BeagleBone Black for audio. Currently 
our resources are pretty scarce, but hopefully from March things should get 
better For instance, now that RobertCNelson has discontinued support for 
Xenomai on the BeagleBone, we may be able to help with that (incidentally - as 
someone was asking - we provide a pre-built image for BeagleBone with Debian 
Stretch and  Xenomai 3.0.5 on Linux 4.4 (and some of our stuff too): 
https://github.com//BelaPlatform/bela-image-builder/releases).

> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely

Either way, it would be great to be able to take part in this workshop with 
Philippe. I think it is unlikely that we would be able to travel to Munich in 
January, but we should be able to attend remotely, so please keep us in the 
loop. I reckon it would be important (if all the involved parties agree, that 
is) to make a video recording of the workshop available online for posterity 
(e.g.: a youtube live streaming and subsequently available permanently), so to 
make it easier for others in the future to get started with Xenomai's 
development.

Thanks,
Giulio


From: Xenomai  on behalf of Henning Schild 

Sent: 23 November 2017 12:21
To: Jan Kiszka
Cc: Daniel Wagner; Xenomai@xenomai.org
Subject: Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka :

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.
>
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.

> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
>
>  - building up a core team of kernel maintainers for Cobalt
>
>  - offloading work from the shoulders of our extremely valuable
>maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
>
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
>
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and 

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 01:52 PM, Henning Schild wrote:

Am Thu, 23 Nov 2017 12:42:08 +0100
schrieb Philippe Gerum :


On 11/22/2017 09:27 PM, Jan Kiszka wrote:

On 2017-11-22 16:32, Philippe Gerum wrote:

Hi Kendall,

On 11/21/2017 08:27 PM, Auel, Kendall wrote:

Hi Philippe,

Is there an online bug tracking and feature request database?
This would be a useful way to distribute work and to sync up
contributors. I think the kernel uses Bugzilla, and Ubuntu has
Launchpad. No doubt there are many others.

I'd like to contribute in some way. I've been having a lot of fun
as a Xenomai user.

We don't have that unfortunately. As suggested by several posters,
moving to a git-based, integrated development framework such as
gitlab or github would bring in that feature, and others we need
too (CI).

I have no issue moving the project from the current git server at
xenomai.org to any of these environments.
  

If it helps the community to grow, I would not refuse such a move.
But I would like to raise some concerns about platforms like github
or gitlab that we must be aware of:

- lacking integration with email-based workflows (while kernel
   development tends to be based on that...)

- risk of decoupling communities when parts of the discussions
happen on tickets or PRs and parts in mailing list threads

Therefore, most projects I manage on github and in our internal
gitlab have clear policies like "no emails, only tickets and PRs"
or "no PRs, only patches on the mailing list". Even just using the
issue tracker to keep some to-do list requires discipline to direct
discussions consequently to a mailing list if that exists as well
(and that usually does not work very well).

IOW: we need to be clear in what we want a platform for - and what
not.

Forking the original thread to get input from the list specifically
regarding the idea of moving GIT services from xenomai.org to a public
software development platform.

As Jan mentioned, there is more than having GIT underneath, there are
deep implications on the workflow, and it really depends on what we'd
want from such platform. If you have any thought, recommendation,
experience with those platforms in your daily work, it would be great
to know your views.

Jan is absolutely right here. Before moving to github (or something
alike) you need to set groundrules for how to deal with PRs, issues and
all the stuff that you suddenly gain.

I think Xenomai could benefit from issue tracking and CI, not sure
whether we need github for that.


issue tracking is not something that important IMO.
I dont believe this is extensively used by any projects but mainly distros.


The CI they offer is docker-based and
we would likely want something more powerful. But i guess you could
always use docker to remote control AWS or real hardware.


yes. there are a number of solutions that in fact do OTA and most of 
them use Docker to control real hardware.
the industry seems to be going in that direction. I think Shippable 
should server our purpose.


for instance, check out this commit:
https://github.com/zephyrproject-rtos/zephyr/pull/5134

and its shippable output
https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console


github sucks at routing mails. My github account is shared between my
work and personal stuff but i do not star/watch any work related
projects because i do not want the notifications in my personal inbox.


I agree that it sucks but I dont see why this should be an issue.
Just dont rely on github emails (I personally tend to disable them, they 
are extremely annoying).


when I need to find out how any PR is progressing (every other day) I 
just connect to github.




commitment to github etc. is likely to cause sort of a vendor lock-in.


? what do you mean?

I am sure the APIs can be used to extract some information, but will you
get something that you can import into your own gitlab or track later
on? As long as we only use git-hosting and CI from them that would not
be too much of a problem.


yeah everything can be done (ie: at linaro we have lava-labs and 
integrate our own CI loops with Jenkins and real hardware).

But I dont believe Xenomai has the dedicated resources for that.

BTW at ELCE in Prague, Tgx's daughter presented a very interesting 
approach [1] to accessing real hardware on CI (using libvirt). Very cool.
I think we should use it if in the end we decide to roll our own. But 
IMO, Shippable should suffice.


[1] 
https://osseu17.sched.com/event/ByYA/continuous-integration-jenkins-libvirt-and-real-hardware-anna-maria-gleixner-manuel-traut-linutronix-gmbh





Henning


Thanks,



___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai




___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Henning Schild]

Am Thu, 23 Nov 2017 12:42:08 +0100
schrieb Philippe Gerum :

> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> > On 2017-11-22 16:32, Philippe Gerum wrote:  
> >>
> >> Hi Kendall,
> >>
> >> On 11/21/2017 08:27 PM, Auel, Kendall wrote:  
> >>> Hi Philippe,
> >>>
> >>> Is there an online bug tracking and feature request database?
> >>> This would be a useful way to distribute work and to sync up
> >>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
> >>> Launchpad. No doubt there are many others.
> >>>
> >>> I'd like to contribute in some way. I've been having a lot of fun
> >>> as a Xenomai user. 
> >> We don't have that unfortunately. As suggested by several posters,
> >> moving to a git-based, integrated development framework such as
> >> gitlab or github would bring in that feature, and others we need
> >> too (CI).
> >>
> >> I have no issue moving the project from the current git server at
> >> xenomai.org to any of these environments.
> >>  
> > 
> > If it helps the community to grow, I would not refuse such a move.
> > But I would like to raise some concerns about platforms like github
> > or gitlab that we must be aware of:
> > 
> > - lacking integration with email-based workflows (while kernel
> >   development tends to be based on that...)
> > 
> > - risk of decoupling communities when parts of the discussions
> > happen on tickets or PRs and parts in mailing list threads
> > 
> > Therefore, most projects I manage on github and in our internal
> > gitlab have clear policies like "no emails, only tickets and PRs"
> > or "no PRs, only patches on the mailing list". Even just using the
> > issue tracker to keep some to-do list requires discipline to direct
> > discussions consequently to a mailing list if that exists as well
> > (and that usually does not work very well).
> > 
> > IOW: we need to be clear in what we want a platform for - and what
> > not. 
> 
> Forking the original thread to get input from the list specifically
> regarding the idea of moving GIT services from xenomai.org to a public
> software development platform.
> 
> As Jan mentioned, there is more than having GIT underneath, there are
> deep implications on the workflow, and it really depends on what we'd
> want from such platform. If you have any thought, recommendation,
> experience with those platforms in your daily work, it would be great
> to know your views.

Jan is absolutely right here. Before moving to github (or something
alike) you need to set groundrules for how to deal with PRs, issues and
all the stuff that you suddenly gain.

I think Xenomai could benefit from issue tracking and CI, not sure
whether we need github for that. The CI they offer is docker-based and
we would likely want something more powerful. But i guess you could
always use docker to remote control AWS or real hardware.

github sucks at routing mails. My github account is shared between my
work and personal stuff but i do not star/watch any work related
projects because i do not want the notifications in my personal inbox.

commitment to github etc. is likely to cause sort of a vendor lock-in.
I am sure the APIs can be used to extract some information, but will you
get something that you can import into your own gitlab or track later
on? As long as we only use git-hosting and CI from them that would not
be too much of a problem.

Henning

> Thanks,
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 12:42 PM, Philippe Gerum wrote:

On 11/22/2017 09:27 PM, Jan Kiszka wrote:

On 2017-11-22 16:32, Philippe Gerum wrote:

Hi Kendall,

On 11/21/2017 08:27 PM, Auel, Kendall wrote:

Hi Philippe,

Is there an online bug tracking and feature request database? This would be a 
useful way to distribute work and to sync up contributors. I think the kernel 
uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.

I'd like to contribute in some way. I've been having a lot of fun as a Xenomai 
user.


We don't have that unfortunately. As suggested by several posters,
moving to a git-based, integrated development framework such as gitlab
or github would bring in that feature, and others we need too (CI).

I have no issue moving the project from the current git server at
xenomai.org to any of these environments.


If it helps the community to grow, I would not refuse such a move. But I
would like to raise some concerns about platforms like github or gitlab
that we must be aware of:

- lacking integration with email-based workflows (while kernel
   development tends to be based on that...)

- risk of decoupling communities when parts of the discussions happen on
   tickets or PRs and parts in mailing list threads

Therefore, most projects I manage on github and in our internal gitlab
have clear policies like "no emails, only tickets and PRs" or "no PRs,
only patches on the mailing list". Even just using the issue tracker to
keep some to-do list requires discipline to direct discussions
consequently to a mailing list if that exists as well (and that usually
does not work very well).

IOW: we need to be clear in what we want a platform for - and what not.


Forking the original thread to get input from the list specifically
regarding the idea of moving GIT services from xenomai.org to a public
software development platform.

As Jan mentioned, there is more than having GIT underneath, there are
deep implications on the workflow, and it really depends on what we'd
want from such platform. If you have any thought, recommendation,
experience with those platforms in your daily work, it would be great to
know your views.


In the past year alone I have been contributing to uboot (as board 
maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 
support), zephyr (multiple drivers), the linux kernel (some fixes), AOSP 
(fixes) and a few others. So I have gained certain exposure to a number 
of workflows.


with this in mind I think the Zephyr workflow would suit Xenomai nicely.

It spins around Github and integrates with Shippable - this means that 
on each pull request, we can trigger a full rebuild and run sanity and 
maybe even performance tests before any code review can begin; the 
subsystem maintainer/s then can review the pull request adding comments 
on the code as it moves along.


Xenomai also lacks an IRC channel which makes things way too quiet for a 
small size community (in the case of ffmpeg for instance IRC is where 
most if not all the discussions happen). IRC is - and should be for 
Xenomai- a good place to ask for help and direction. So I vote for 
having one.


To sum up, given the low rate of patches that Xenomai handles and given 
the need push back on performance degradation I strongly believe that 
the Zephyr's workflow would work for us. The way performance 
ramifications are maintained today is pretty much living in Philippe's 
and possibly Jan's head: I think we should move from intuition to 
explicit measurable data when merging PRs (ie, establishing a 
multi-board CI loop)







___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

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.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Henning Schild]

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka :

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.  
> 
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.
 
> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
> 
>  - building up a core team of kernel maintainers for Cobalt
> 
>  - offloading work from the shoulders of our extremely valuable
>maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
> 
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
> 
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and integration paths
>  - update strategy and frequency
>  - testing needs and strategies
>  - supportable architectures
>  - state and details of the new pipeline design
>  - planning of and migration path to the new design
> 
> If there is interest in joining such a discussion, physically (will
> likely take place in our office in Munich, Germany) or virtually
> (provided time zones work out), please let us know. Time frame is more
> likely early next year than mid of this December. And this shall be
> only the kickoff for further discussions in the community!

Yes, anyone that wants to join such a meeting please let us know.
Depending on the feedback we could also arrange something different.
(i.e. collocated with FOSDEM18? )

Henning

> Jan
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[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?

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] Fix compilation of e1000, eepro100 and igp rtnet drivers

[Philippe Gerum]

On 11/23/2017 08:29 AM, Leopold Palomo-Avellaneda wrote:
> On 21/11/17 14:00, Norbert Lange wrote:
>> Hello,
>>
>> enabling RTNet will result in compile failures, because there is a
>> nameclash from some linux-headers.
>> This patch fixes some intel NICs to compile
> 
> I have applied this patch and seems that works quiet well.
> 
> Philippe, is this a correct solution?
> 
> Could be applied the same for the rest of the drivers with the same problem?
> 

Yes, the fix makes sense. I merged it.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] Fix compilation of e1000, eepro100 and igp rtnet drivers

[Philippe Gerum]

On 11/21/2017 02:00 PM, Norbert Lange wrote:
> Hello,
> 
> enabling RTNet will result in compile failures, because there is a
> nameclash from some linux-headers.
> This patch fixes some intel NICs to compile

Merged, thanks.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai-git] Norbert Lange : rtnet/driver: fix compilation of intel drivers

[git repository hosting]

Module: xenomai-3
Branch: stable-3.0.x
Commit: 3fb574cd1b69487c20f58b56332e0858032c6f21
URL:
http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=3fb574cd1b69487c20f58b56332e0858032c6f21

Author: Norbert Lange 
Date:   Tue Nov 21 11:57:28 2017 +0100

rtnet/driver: fix compilation of intel drivers

the local debug variable has a name-clash with a identically named
function in arch/x86/include/asm/traps.h
also a macro guard apparently used an outdated name

Signed-off-by: Norbert Lange 

---

 kernel/drivers/net/drivers/e1000/e1000_main.c |6 +++---
 kernel/drivers/net/drivers/eepro100.c |   20 ++--
 kernel/drivers/net/drivers/igb/igb_main.c |6 +++---
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/kernel/drivers/net/drivers/e1000/e1000_main.c 
b/kernel/drivers/net/drivers/e1000/e1000_main.c
index 51e9a82..f53207b 100644
--- a/kernel/drivers/net/drivers/e1000/e1000_main.c
+++ b/kernel/drivers/net/drivers/e1000/e1000_main.c
@@ -243,8 +243,8 @@ MODULE_DESCRIPTION("Intel(R) PRO/1000 Network Driver for 
rtnet");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_VERSION);
 
-static int debug = NETIF_MSG_DRV | NETIF_MSG_PROBE;
-module_param(debug, int, 0);
+static int local_debug = NETIF_MSG_DRV | NETIF_MSG_PROBE;
+module_param_named(debug, local_debug, int, 0);
 MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
 
 
@@ -734,7 +734,7 @@ static int e1000_probe(struct pci_dev *pdev,
adapter->netdev = netdev;
adapter->pdev = pdev;
adapter->hw.back = adapter;
-   adapter->msg_enable = (1 << debug) - 1;
+   adapter->msg_enable = (1 << local_debug) - 1;
 
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
diff --git a/kernel/drivers/net/drivers/eepro100.c 
b/kernel/drivers/net/drivers/eepro100.c
index 6d54643..11b4cf4 100644
--- a/kernel/drivers/net/drivers/eepro100.c
+++ b/kernel/drivers/net/drivers/eepro100.c
@@ -52,7 +52,7 @@ static int multicast_filter_limit = 64;
e.g. "options=16" for FD, "options=32" for 100mbps-only. */
 static int full_duplex[] = {-1, -1, -1, -1, -1, -1, -1, -1};
 static int options[] = {-1, -1, -1, -1, -1, -1, -1, -1};
-static int debug = -1; /* The debug level */
+static int local_debug = -1;   /* The debug level */
 
 /* A few values that may be tweaked. */
 /* The ring sizes should be a power of two for efficiency. */
@@ -120,7 +120,7 @@ MODULE_PARM_DESC(cards, "array of cards to be supported 
(e.g. 1,0,1)");
 MODULE_AUTHOR("Maintainer: Jan Kiszka ");
 MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver");
 MODULE_LICENSE("GPL");
-module_param(debug, int, 0444);
+module_param_named(debug, local_debug, int, 0444);
 module_param_array(options, int, NULL, 0444);
 module_param_array(full_duplex, int, NULL, 0444);
 module_param(txfifo, int, 0444);
@@ -1823,14 +1823,14 @@ static struct pci_driver eepro100_driver = {
 
 static int __init eepro100_init_module(void)
 {
-#ifdef RTNET_DRV_EEPRO100_DBG
-   if (debug >= 0 && speedo_debug != debug)
-   printk(KERN_INFO "eepro100.c: Debug level is %d.\n", debug);
-   if (debug >= 0)
-   speedo_debug = debug;
-#else  /* !RTNET_DRV_EEPRO100_DBG */
-   debug = speedo_debug; /* touch debug variable */
-#endif /* RTNET_DRV_EEPRO100_DBG */
+#ifdef CONFIG_XENO_DRIVERS_NET_DRV_EEPRO100_DBG
+   if (local_debug >= 0 && speedo_debug != local_debug)
+   printk(KERN_INFO "eepro100.c: Debug level is %d.\n", 
local_debug);
+   if (local_debug >= 0)
+   speedo_debug = local_debug;
+#else  /* !CONFIG_XENO_DRIVERS_NET_DRV_EEPRO100_DBG */
+   local_debug = speedo_debug; /* touch debug variable */
+#endif /* CONFIG_XENO_DRIVERS_NET_DRV_EEPRO100_DBG */
 
return pci_register_driver(_driver);
 }
diff --git a/kernel/drivers/net/drivers/igb/igb_main.c 
b/kernel/drivers/net/drivers/igb/igb_main.c
index 06303f5..fe0132b 100644
--- a/kernel/drivers/net/drivers/igb/igb_main.c
+++ b/kernel/drivers/net/drivers/igb/igb_main.c
@@ -277,9 +277,9 @@ MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_VERSION);
 
 #define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
-static int debug = -1;
-module_param(debug, int, 0);
-MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+static int local_debug = -1;
+module_param_named(debug, local_debug, int, 0);
+MODULE_PARM_DESC(debug, "debug level (0=none,...,16=all)");
 
 struct igb_reg_info {
u32 ofs;


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai-git

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

Hi Steven,

On 11/22/2017 05:49 PM, Steven Seeger wrote:
> Philippe, as we have previously discussed I am willing to take over the PPC i-
> pipe maintenance on my personal time if it will help.

Thanks, that would be great.

 My only issue is right
> now the only PPC board I have in my posseession is an 8548-based board. I 
> might be able to borrow some 405 and 440-based boards from work if needed. Of 
> course, we can always depend on the grateful Xenomai users for test and 
> feedback. :)
>

I have remote access to many ppc boards and could help here. This said
85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
- maybe adding mpc52xx would be good, I have one here. I don't see much
traction these days for Xenomai over ppc64, so I'm not even sure whether
this port is still relevant.

> I am not sure my group is going to pursue RTNET otherwise I would have been 
> happy to help there. I think negotations are still open on that one, though.
> 
> If we ever get around to releasing my microblaze i-pipe patch then I am happy 
> to maintain that as well. :) Feel free to email me privately if you want to 
> discuss.

Ok.

> 
> I really miss Gilles and maybe I can help carry on his memory in some small 
> way. Hopefully he is in heaven where there are no geode CPUs to chase FPU 
> bugs 
> on :)


-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 01:33 PM, Leopold Palomo-Avellaneda wrote:

[snip]

> 
> And finally, if you let me talk about our Elmer.
> 
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people have
> interest.
>

For the record, I'm definitely not suggesting to drop all I/O device
support from Xenomai, that would obviously make no sense. However, the
broken code must be fixed otherwise it serves no purpose but annoying
both users and maintainers.

> But I would like to ask you directly Philippe some practical steps that could
> address to this challenge:
> 
> - Would you be willing to move Xenomai to some platform like github, or 
> similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
> 

Yes.

> - Would you be willing to delegate tasks of the project to other people,

Yes.

 that
> maybe will not make it as good as you will do, like documentation, web site, 
> or
> parts of code, but made then with an acceptable quality?

Yes. This said, acceptable quality is a matter of taste and perception,
and the people involved in the merging process may have different views
on this. Fortunately for us, crap always solidly looks crap, which eases
the decision process when deciding what to do with it.

 And please, don't take
> bad, it's a difficult thing. I have to confess that for me, it's very 
> difficult.
> > - Would you be willing to guide new contributors and give them
responsibilities
> of important parts of the code?
> 

Yes. However, we cannot expect anyone to decide for us what we could be
interested in contributing. What needs to be done can be put on the
table for discussion, people may add new ideas, but at the end of the
day, one is responsible for committing to a task.

> - Would you be willing to have the role as coordinator and leader of the 
> project
> changing from one man show to some more open project? will be it possible? I

This is already the situation today, the real issue is that I'm
contributing most of the code, and have to carry out all of the other
tasks in the project, which ends up with nothing being done with the
required level of predictability and quality.

Even more importantly, most of the knowledge about how things work
internally all across the core system over all CPU architectures is
dangerously concentrated into a single person's brain. With a bus factor
of 1, well, Houston, we have a problem.

Information must flow, as a matter of fact, it does not, at the very
least not enough. This is clearly not a matter of unwillingness from my
end, but I tend to get lazy writing documentation about the internal
stuff when I'm not explicitly challenged to provide information by
people involved in the project.

> don't know if because license issues or whatever would let it...
>

The licensing scheme is very simple (fully abide by the kernel GPL
license for anything living in kernel space, use LGPL for libs in
userland) and did not change for the past 15 years, I'm not aware of any
issue so far.

> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a 
> barrier
> for the new contributors, at least in another opensource projects. However, I
> have to admit that the entry level in Xenomai is high, so, autotools should 
> not
> be a problem.

I'm not excluding any change at this stage, which includes considering
other options in replacement of the autotools. This said, I don't think
the tool supporting build recipes can prevent anyone to contribute
software. In kernel space, Kbuild has to be followed and autotools are
not involved at all. In user-space, a recipe to build an exec or a
library is about 10 lines of a Makefile template, with many examples
around. And the mailing list has always been there for people to ask
specific questions about this.

> 
> And yes, the lost of Gilles was a great blow, on a the personal level and for
> his contributions on the project.
> 
>>From my part, I can contribute if there's interest, in Debian (Ubuntu) 
>>packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm. So, I
> could try to provide some preconfigured scenarios to the people that would 
> like
> to entry in Xenomai.
> 
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to RT_PREMPT. 
> But,
> because its history and my "affection" for the project I would prefer stay 
> with
> it and try to help.
> 

Talking about the elephant in the room does not make it scarier, it has
always been there.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org

[Xenomai] I am trying to make a hard real-time application on Xenomai (dual-kernel configuration). Here are some questions.

[김범진]

   Hello,
   I am trying to make a hard real-time application on Xenomai
   (dual-kernel configuration). Here are some questions.


   1. To fully utilize the realtime capability of Xenomai, should I apply
   xenomai to all the associated application libraries?
   For example, if I run the 'ldd' command with my real-time application,
   the output looks like this:

   linux-vdso.so.1 =>  (0x7ffec45e6000)
   liburdfdom_model.so.1.0 =>
   /opt/ros/r2b3/lib/x86_64-linux-gnu/liburdfdom_model.so.1.0
   (0x7f1d34afb000)
   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
   (0x7f1d34727000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
   (0x7f1d3450f000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
   (0x7f1d34145000)
   libtinyxml.so.2.6.2 =>
   /usr/lib/x86_64-linux-gnu/libtinyxml.so.2.6.2 (0x7f1d33f2f000)
   libconsole_bridge.so.0.3 =>
   /opt/ros/r2b3/lib/x86_64-linux-gnu/libconsole_bridge.so.0.3
   (0x7f1d33d29000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
   (0x7f1d33a2)
   /lib64/ld-linux-x86-64.so.2 (0x56478f1a2000)

   Do I need to rebuild all libraries in the output list (libstdc ++,
   libtinyxml ...) by applying the xenomai compile option?


   2. I cannot find 'poll()' syscall from Xenomai sources (also, in
   cobalt.wrappers). Is there any reason to omit the poll() syscall from
   Xenomai? How do I re-build POSIX-based existing code using
   poll()/epoll() with Xenomai?


   3. I tried to apply Xenomai to a broadly-used library named
   libPocoFoundation. But it throws exception at pthread_mutex_init() as
   shown below.
   ([1]https://github.com/pocoproject/poco/blob/develop/Foundation/src/Mut
   ex_POSIX.cpp:64)

if (pthread_mutex_init (& _ mutex, & attr))
{
pthread_mutexattr_destroy (& attr);
throw SystemException ("can not create mutex");
}

   If you refer to manpage, pthread_mutex_init() cannot have '1' as return
   value. However, pthread_mutex_init() of Xenomai actually returns '1' as
   errorno. As the result, the application is aborted.
   I want to know the reason of this phenomenon.


   Thank you!


   Beomjin Kim | Engineer

   Applied Platform Team. | Software R Center | Samsung Electronics Co.,
   Ltd.

   Mobile : +82-10-8495-5520 | E-Mail : [2]beomjins@samsung.com


   [cid:cafe_image_0@s-core.co.kr]

   [update?userid=beomjins.kim=bWFpbElEPTIwMTcxMTIzMDkwMDM1ZXBjbXMxcDg1
   MWNiYjZhN2EwMzViNTczZTM0MDAyOGUzNDlmMTI1NCZyZWNpcGllbnRBZGRyZXNzPXhlbm9
   tYWlAeGVub21haS5vcmc_]

References

   1. 
https://github.com/pocoproject/poco/blob/develop/Foundation/src/Mutex_POSIX.cpp:64
   2. mailto:beomjins@samsung.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13402 bytes
Desc: not available
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20171123/00c79293/attachment.gif>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai