Re: [Xenomai] 4.9 for x86 issue

[Jan Kiszka]

On 2018-03-27 15:12, Philippe Gerum wrote:
> On 03/10/2018 11:06 PM, Jan Kiszka wrote:
>> On 2018-03-09 08:51, Jan Kiszka wrote:
>>> 4.9 requires more work, I've pushed the beginning to wip/4.9 in the same
>>> repo.
>>
>> I started to patch further on this during my flight (wip/4.9 updated),
>> noticed that the 4.14-wip queue will need a little bit sysentry tweaking
>> as well (missing 64-bit syscall dispatching), and then had to find 4.9
>> in a rather unfortunate state /wrt x86-64: CPUs are no longer idling
>> properly. I went back to ipipe-core-4.9.24-x86-2, without a difference.
>>
>> If you should look into 4.9-x86 as you indicated, please check this.
> 
> Both issues fixed in 4.9.90/x86 as pushed lately. The result has run
> overnight in 64bit mode, and for a couple of hours in ia32emu mode. So
> far so good.

Just trying 4.9.90-x86-6 in KVM, and I'm still finding 100% (virtual)
CPU load. I also triggered this with stable-3.0.x:

[  237.455846] WARNING: CPU: 0 PID: 1055 at 
../kernel/xenomai/posix/timerfd.c:57 timerfd_read+0x2a6/0x350
[  237.460728] Modules linked in:
[  237.461490] CPU: 0 PID: 1055 Comm: sampling-1052 Not tainted 4.9.90+ #11
[  237.461490] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
[  237.461490] I-pipe domain: Xenomai
[  237.461490]  c90001b7fdb0 8145e395  

[  237.461490]  c90001b7fdf0 810e7261 00393d61d170 
c93e6008
[  237.461490]  0003 0008 7f513e8c2de8 
00026200
[  237.461490] Call Trace:
[  237.461490]  [] dump_stack+0xb2/0xdd
[  237.461490]  [] __warn+0xd1/0xf0
[  237.461490]  [] warn_slowpath_null+0x1d/0x20
[  237.461490]  [] timerfd_read+0x2a6/0x350
[  237.461490]  [] rtdm_fd_read+0x13c/0x3b0
[  237.461490]  [] ? CoBaLt_ioctl+0x20/0x20
[  237.461490]  [] CoBaLt_read+0xe/0x10
[  237.461490]  [] handle_head_syscall+0x184/0x4b0
[  237.461490]  [] ipipe_fastcall_hook+0x18/0x20
[  237.461490]  [] ipipe_handle_syscall+0x64/0x110
[  237.461490]  [] do_syscall_64+0x43/0x1c0
[  237.461490]  [] entry_SYSCALL_64_after_swapgs+0x5d/0xdb
[  237.461490] ---[ end trace 9d2476a38b0c5379 ]---

I will debug this tomorrow.

Jan

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20180405/a998b4ce/attachment.sig>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

Hello,

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Donnerstag, 05. April 2018 16:55
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
 >Subject: Re: building Xenomai Apps with CMake (RFC)
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >On 2018-04-03 16:10, Lange Norbert wrote:
 >> Hello,
 >>
 >> I went ahead and created a script to add support for Xenomai (3+) to CMake.
 >Its currently sufficient for me,
 >> but I would like to get this in a shape that it is useful and robust enough 
 >> for
 >most people.
 >> Ultimately it should end up up streamed to CMake (I hope the 
 >> binutils-specific
 >wrappers aren't a knock-out against adoption).
 >>
 >> Mostly this should interest people that want to use CMake, but a few things
 >might need support from the Xenomai distribution.
 >> To be more specific: using precompiled object-files like the boostrap code
 >and its linker wraps and redirections are something I would
 >> like to avoid, or atleast offer an alternative that does not need that much
 >work outside of a "regular build".
 >> For that, having the bootstrap code (configurable or a few variants) 
 >> installed
 >as sourcecode would help.
 >>
 >> Code is uploaded to Github : https://github.com/nolange/cmake_xenomai
 >
 >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
 >well who looked into cmake, need to check the status and scope again
 >(maybe Henning knows more). Could be interesting, indeed.

If I may ask, are you using the "boostraps" from Xenomai or some own init-code?
(that’s currently the biggest headache remaining)

 >
 >For my understanding: You need cmake upstream changes to make things
 >work? Or is this project something that could eventually be carried in
 >Xenomai upstream, just requiring some cmake version >= X?

No strict need to upstream the scripts in either Xenomai or CMake, the files 
just need to be in the search-path of CMake to be usable (likely doesnt need 
anything newer than CMake 3.0 but would need to test this).
I value the feedback from both communities, particularly because I don’t use 
anything but the Posix/Cobalt Skin
and getting it into CMake would be the best thing for maintenance.

Nevertheless it could be really helpful to add a headerfile in the Xenomai 
distribution, replicating the steps that 'boilerplate/init/bootstrap.c' does,
and allowing to disable parts of the functionality like the main wrapper.
That glue code would ideally be built together with libraries/executables using 
it (identical flags and such).
Right now the code is mostly duplicated and placed with the CMake Scripts, 
which is not ideal.

Norbert


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

Re: [Xenomai] ipipe: fix preemption damage in hard_preempt_enable()

[Jan Kiszka]

On 2018-04-05 17:08, Philippe Gerum wrote:
> On 04/05/2018 04:49 PM, Jan Kiszka wrote:
>> Hi Philippe,
>>
>> to assess the impact of the bug that the mentioned commit fixes, can you
>> describe the code path that trigger it?
>>
> 
> e.g. in the rtnet stack, calling rtdev_get_by_name() on a PREEMPT
> kernel, and a regular rescheduling pending at the time of the call.
> 
> rtdev_get_by_name()
>   -> rtdm_lock_irqsave(...)
>   -> rtdev_reference(...)
> -> try_module_get()
>   hard_preempt_disable(); /* hard IRQs were off */
>   ...
>   hard_preempt_enable();
>  -> hard_local_irq_restore() /* still off */
>  -> preempt_check_resched(); /* resched pending */
><>
> 
> This went unnoticed until I got some changes in creating a resched
> opportunity right on spot...

Hmm, ok. I suspect (/hope) that this case is a rather RTnet-specific case.

Jan

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

Re: [Xenomai] ipipe: fix preemption damage in hard_preempt_enable()

[Philippe Gerum]

On 04/05/2018 04:49 PM, Jan Kiszka wrote:
> Hi Philippe,
> 
> to assess the impact of the bug that the mentioned commit fixes, can you
> describe the code path that trigger it?
> 

e.g. in the rtnet stack, calling rtdev_get_by_name() on a PREEMPT
kernel, and a regular rescheduling pending at the time of the call.

rtdev_get_by_name()
  -> rtdm_lock_irqsave(...)
  -> rtdev_reference(...)
-> try_module_get()
  hard_preempt_disable(); /* hard IRQs were off */
  ...
  hard_preempt_enable();
 -> hard_local_irq_restore() /* still off */
 -> preempt_check_resched(); /* resched pending */
   <>

This went unnoticed until I got some changes in creating a resched
opportunity right on spot...

-- 
Philippe.

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

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Jan Kiszka]

On 2018-04-03 16:10, Lange Norbert wrote:
> Hello,
> 
> I went ahead and created a script to add support for Xenomai (3+) to CMake. 
> Its currently sufficient for me,
> but I would like to get this in a shape that it is useful and robust enough 
> for most people.
> Ultimately it should end up up streamed to CMake (I hope the 
> binutils-specific wrappers aren't a knock-out against adoption).
> 
> Mostly this should interest people that want to use CMake, but a few things 
> might need support from the Xenomai distribution.
> To be more specific: using precompiled object-files like the boostrap code 
> and its linker wraps and redirections are something I would
> like to avoid, or atleast offer an alternative that does not need that much 
> work outside of a "regular build".
> For that, having the bootstrap code (configurable or a few variants) 
> installed as sourcecode would help.
> 
> Code is uploaded to Github : https://github.com/nolange/cmake_xenomai

Thanks for sharing this. IIRC, we have some Xeommai user in-house as
well who looked into cmake, need to check the status and scope again
(maybe Henning knows more). Could be interesting, indeed.

For my understanding: You need cmake upstream changes to make things
work? Or is this project something that could eventually be carried in
Xenomai upstream, just requiring some cmake version >= X?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] ipipe: fix preemption damage in hard_preempt_enable()

[Jan Kiszka]

Hi Philippe,

to assess the impact of the bug that the mentioned commit fixes, can you
describe the code path that trigger it?

Thanks
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Context switching with POSIX skin

[rodrigo . amaducci]

Quoting Philippe Gerum :


You need to enable the ipc/xddp driver (CONFIG_XENO_DRIVERS_RTIPC_XDDP)
in your kernel.

--
Philippe.


I have recompiled my kernel a couple of times activating all the RTIPC  
drivers but I'm still getting the same error when running xddp-echo.


Rodrigo






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

Re: [Xenomai] doc for xeno-config skins

[Philippe Gerum]

On 04/05/2018 01:39 PM, Giulio Moro wrote:
> Thanks and sorry for overlooking that. I thought if there was some docs on 
> xeno-config it would have been inlined in its source, so that is where I 
> looked for it. I guess the man folder should have been a more obvious choice.
> 
> Is it correct that calling `xeno-config --skin cobalt` expects you to call, 
> POSIX functions prefixed with `__wrap_` ? Does this mean that the *actual* 
> "Cobalt POSIX interface" consists of __wrap_fn() calls as opposed to fn() 
> calls?

__RT(fn()) and __COBALT(fn()) hide this ugly __wrap prefix inside an
ugly macro. __STD() keeps consistent with such ugliness for __real calls.

> If yes,  is this documented somewhere obvious?
 I kind of figured this out over time by reading
http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/
 and looking at the wrappers files and at the source code, but is it
stated clearly somewhere?

Of course not. Proper documentation hinders fruitful imagination.

> This is a place where I would have looked for that, for instance: 
> http://www.xenomai.org/documentation/xenomai-3/html/xeno3prm/group__cobalt__api.html
>  .
> 

Makes sense, added to my todo list. This is part of a larger
documentation work.

> (incidentally, these two images (referenced by the xeno-config man page) are 
> missing
> http://www.xenomai.org/documentation/xenomai-3/html/man1/asciidoc-icons/note.png
> http://www.xenomai.org/documentation/xenomai-3/html/man1/asciidoc-icons/caution.png
> )
>

Ok, thanks.

-- 
Philippe.

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

[Xenomai] xeno-config --no-mode-check still has -lmodechk

[Philippe Gerum]

On 04/05/2018 01:15 PM, Giulio Moro wrote:
> so would it not be up to the external libs to specify in their docs that they 
> should be linked with -lmodechk?

You likely mean mentioning such dependency in their LDFLAGS as DSOs when
linked, which is right.

Over time, I received several reports from users of 3rd party libs which
could not assume that unfortunately. So the question boils down to:
should we break those builds to remove a generally useless dependency on
libmodechk, or should we keep this dependency to please those users and
maintain backward compat.

Another question this raises is about calling __real_* symbols directly
from the application code - which would be ok as a way to bypass the
assertion checking in this case (likewise the other way around,
referring to __wrap* calls). Not depending on libmodechk would
invalidate such usage, ending up in undefined references.

Open question AFAIC.

-- 
Philippe.

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

Re: [Xenomai] doc for xeno-config skins

[Giulio Moro]

Thanks and sorry for overlooking that. I thought if there was some docs on 
xeno-config it would have been inlined in its source, so that is where I looked 
for it. I guess the man folder should have been a more obvious choice.

Is it correct that calling `xeno-config --skin cobalt` expects you to call, 
POSIX functions prefixed with `__wrap_` ? Does this mean that the *actual* 
"Cobalt POSIX interface" consists of __wrap_fn() calls as opposed to fn() calls?
If yes,  is this documented somewhere obvious? I kind of figured this out over 
time by reading 
http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/  
and looking at the wrappers files and at the source code, but is it stated 
clearly somewhere? 
This is a place where I would have looked for that, for instance: 
http://www.xenomai.org/documentation/xenomai-3/html/xeno3prm/group__cobalt__api.html
 .

(incidentally, these two images (referenced by the xeno-config man page) are 
missing
http://www.xenomai.org/documentation/xenomai-3/html/man1/asciidoc-icons/note.png
http://www.xenomai.org/documentation/xenomai-3/html/man1/asciidoc-icons/caution.png
)

Thanks,
Giulio

From: Philippe Gerum 
Sent: 05 April 2018 07:36
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] doc for xeno-config skins

On 04/04/2018 10:15 PM, Giulio Moro wrote:
> What is the difference between the Posix and Cobalt skin, as far as 
> xeno-config is concerned??
>
> Difference between
>   xeno-config --skin posix --cflags
>   xeno-config --skin cobalt --cflags
> is that the former declares -D__COBALT_WRAP__ (which in turn adds fwd 
> declarations for clock_nanosleep() and pthread_setname_np() in 
> boilerplate/libc.h).
>
> difference between
>   xeno-config --skin posix --ldflags
>   xeno-config --skin cobalt --ldflags
> is that the former adds `-Wl,@/usr/xenomai/lib/cobalt.wrappers`
>
> So it seems to me that `--skin posix` expects you to call, e.g.: 
> pthread_create(), while `--skin cobalt` expects you to call, e.g.: 
> __wrap_pthread_create()
>
> Is this correct?
> Is that it?
> What are the intended uses?
> I don't think this is documented anywhere? Where would be the best place to 
> have this written down? Perhaps the --help of xeno-config? Also, while we are 
> at it, --skin alchemy vs --skin native and the effect of --compat could use 
> some description.
>

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



--
Philippe.

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

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

[Giulio Moro]

so would it not be up to the external libs to specify in their docs that they 
should be linked with -lmodechk?

From: Philippe Gerum 
Sent: 05 April 2018 07:43
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

On 04/04/2018 09:58 PM, Giulio Moro wrote:
>  /usr/xenomai/bin/xeno-config --skin cobalt --ldflags --no-mode-check
>
> returns
> -Wl,--no-as-needed   /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main 
> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt 
> -lmodechk -lpthread -lrt
>
> which removes the modechk wrappers, but leaves -lmodechk in. Is this expected?
>
> As I understand it, libmodechk provides implementations for __wrap_malloc, 
> __wrap_free and __real_malloc, __real_free() are these needed even when the 
> wrappers are disabled, or should -lmodechk not be included?
>
>

The main exec may still depend on external libs built with mode checking
wrappers.

--
Philippe.

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

[Xenomai-git] Philippe Gerum : doc/man: xeno-config: rephrase auto-init documentation

[git repository hosting]

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

Author: Philippe Gerum 
Date:   Thu Apr  5 09:00:47 2018 +0200

doc/man: xeno-config: rephrase auto-init documentation

---

 doc/asciidoc/man1/xeno-config.adoc |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/asciidoc/man1/xeno-config.adoc 
b/doc/asciidoc/man1/xeno-config.adoc
index 14acc67..81f67ad 100644
--- a/doc/asciidoc/man1/xeno-config.adoc
+++ b/doc/asciidoc/man1/xeno-config.adoc
@@ -86,8 +86,8 @@ POSIX API.
 
 [NOTE]
 *--native* and *--skin=native* are accepted for backward compatibility
-purpose. They are stricly equivalent as passing *--alchemy --compat*.
-Likewise, passing *--rtdm* or *--skin=rtdm* is stricly equivalent as
+purpose. They are stricly equivalent to passing *--alchemy --compat*.
+Likewise, passing *--rtdm* or *--skin=rtdm* is stricly equivalent to
 passing *--posix*, enabling POSIX I/O routines to be wrapped to their
 respective Xenomai implementation.
 
@@ -118,17 +118,17 @@ Xenomai libraries.
 *--auto-init*::
 *--no-auto-init*::
 
-All Xenomai APIs but POSIX are based on the Copperplate library, which
-automatically initializes when the application process
-starts. *--no-auto-init* can be passed to disable such
-initialization. In such a case, the application code shall call the
-+copperplate_init()+ routine manually, as part of its initialization
-chores on behalf on the +main()+ routine, *before* any real-time
-service is invoked.
-
-This flag makes sense when passed along with --ldflags
-only. *xeno-config* enables the Copperplate auto-init feature by
-default.
+By default, a process started from an executable linked with flags
+returned by *xeno-config --ldflags* performs Xenomai-related inits
+automatically, before the +main()+ routine is entered.
+
+Building with *--no-auto-init* disables such initialization. In this
+case, the application code shall call the +xenomai_init()+ routine
+manually, as part of its initialization chores on behalf on the
++main()+ routine, *before* any real-time service is invoked. See
++include/xenomai/init.h+.
+
+NOTE: This flag only makes sense when passed along with --ldflags.
 
 *--mode-check*::
 *--no-mode-check*::


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

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

[Philippe Gerum]

On 04/04/2018 09:58 PM, Giulio Moro wrote:
>  /usr/xenomai/bin/xeno-config --skin cobalt --ldflags --no-mode-check
> 
> returns
> -Wl,--no-as-needed   /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main 
> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt 
> -lmodechk -lpthread -lrt
> 
> which removes the modechk wrappers, but leaves -lmodechk in. Is this expected?
> 
> As I understand it, libmodechk provides implementations for __wrap_malloc, 
> __wrap_free and __real_malloc, __real_free() are these needed even when the 
> wrappers are disabled, or should -lmodechk not be included?
> 
> 

The main exec may still depend on external libs built with mode checking
wrappers.

-- 
Philippe.

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

Re: [Xenomai] doc for xeno-config skins

[Philippe Gerum]

On 04/04/2018 10:15 PM, Giulio Moro wrote:
> What is the difference between the Posix and Cobalt skin, as far as 
> xeno-config is concerned??
> 
> Difference between
>   xeno-config --skin posix --cflags
>   xeno-config --skin cobalt --cflags
> is that the former declares -D__COBALT_WRAP__ (which in turn adds fwd 
> declarations for clock_nanosleep() and pthread_setname_np() in 
> boilerplate/libc.h).
> 
> difference between 
>   xeno-config --skin posix --ldflags
>   xeno-config --skin cobalt --ldflags
> is that the former adds `-Wl,@/usr/xenomai/lib/cobalt.wrappers`
> 
> So it seems to me that `--skin posix` expects you to call, e.g.: 
> pthread_create(), while `--skin cobalt` expects you to call, e.g.: 
> __wrap_pthread_create()
> 
> Is this correct?
> Is that it?
> What are the intended uses?
> I don't think this is documented anywhere? Where would be the best place to 
> have this written down? Perhaps the --help of xeno-config? Also, while we are 
> at it, --skin alchemy vs --skin native and the effect of --compat could use 
> some description.
> 

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



-- 
Philippe.

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