Re: [Xenomai] Context switch to secondary mode in xenomai tasks

[Giulio Moro]

or
   cat /proc/xenomai/stat
and see if the count in the MSW column increases for that task

From: Xenomai  on behalf of Greg Gallagher 

Sent: 06 April 2018 18:41
To: C Smith
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] Context switch to secondary mode in xenomai tasks

Check here:
https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/#Chasing_the_unwanted_mode_switches


On Fri, Apr 6, 2018 at 1:39 PM, C Smith  wrote:
> How can we verify which tasks are switching to secondary mode? We know the
> xml parser definitely is switching to secondary mode, setting T_WARNSW,
> causing the application to send the SIGXCPU signal, but we don't know if
> it's affecting the other tasks.
>
> On Fri, Apr 6, 2018 at 10:17 AM, Greg Gallagher 
> wrote:
>>
>> If a tasks switches to secondary mode it would act like a normal Linux
>> thread. I haven't used Xenomai 2.6 in a while but if you are seeing
>> both tasks drop to secondary mode you may want to list the resources
>> that they are sharing and how you are sharing them and then we can see
>> if something would cause mode switches. Are you seeing both threads
>> drop to secondary mode?
>>
>> -Greg
>>
>> On Fri, Apr 6, 2018 at 1:01 PM, C Smith  wrote:
>> > The tasks manipulate shared data however they do not communicate
>> > directly.
>> > The rt_task which parses the xml document and the main rt_task are
>> > running
>> > periodically at different rates using rt_task_set_periodic.
>> >
>> > On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher 
>> > wrote:
>> >>
>> >> Do the tasks communicate with each other?
>> >>
>> >> -Greg
>> >>
>> >> On Fri, Apr 6, 2018 at 12:51 PM, C Smith 
>> >> wrote:
>> >> > Hi all--
>> >> >
>> >> > Our real time application has a main rt_task which runs concurrently
>> >> > with
>> >> > several other rt_tasks (spawned using rt_task_create) and we are
>> >> > concerned
>> >> > about a context switch in one of the tasks. The problematic task uses
>> >> > libxml2 to parse an xml document sent over ethernet which seems to
>> >> > cause
>> >> > a
>> >> > switch to secondary mode. Would this also switch the other tasks we
>> >> > are
>> >> > running to secondary mode, or is it isolated?
>> >> >
>> >> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
>> >> > ___
>> >> > Xenomai mailing list
>> >> > Xenomai@xenomai.org
>> >> > https://xenomai.org/mailman/listinfo/xenomai
>> >
>> >
>
>

___
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] Context switch to secondary mode in xenomai tasks

[Greg Gallagher]

Check here:
https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/#Chasing_the_unwanted_mode_switches


On Fri, Apr 6, 2018 at 1:39 PM, C Smith  wrote:
> How can we verify which tasks are switching to secondary mode? We know the
> xml parser definitely is switching to secondary mode, setting T_WARNSW,
> causing the application to send the SIGXCPU signal, but we don't know if
> it's affecting the other tasks.
>
> On Fri, Apr 6, 2018 at 10:17 AM, Greg Gallagher 
> wrote:
>>
>> If a tasks switches to secondary mode it would act like a normal Linux
>> thread. I haven't used Xenomai 2.6 in a while but if you are seeing
>> both tasks drop to secondary mode you may want to list the resources
>> that they are sharing and how you are sharing them and then we can see
>> if something would cause mode switches. Are you seeing both threads
>> drop to secondary mode?
>>
>> -Greg
>>
>> On Fri, Apr 6, 2018 at 1:01 PM, C Smith  wrote:
>> > The tasks manipulate shared data however they do not communicate
>> > directly.
>> > The rt_task which parses the xml document and the main rt_task are
>> > running
>> > periodically at different rates using rt_task_set_periodic.
>> >
>> > On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher 
>> > wrote:
>> >>
>> >> Do the tasks communicate with each other?
>> >>
>> >> -Greg
>> >>
>> >> On Fri, Apr 6, 2018 at 12:51 PM, C Smith 
>> >> wrote:
>> >> > Hi all--
>> >> >
>> >> > Our real time application has a main rt_task which runs concurrently
>> >> > with
>> >> > several other rt_tasks (spawned using rt_task_create) and we are
>> >> > concerned
>> >> > about a context switch in one of the tasks. The problematic task uses
>> >> > libxml2 to parse an xml document sent over ethernet which seems to
>> >> > cause
>> >> > a
>> >> > switch to secondary mode. Would this also switch the other tasks we
>> >> > are
>> >> > running to secondary mode, or is it isolated?
>> >> >
>> >> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
>> >> > ___
>> >> > 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] Context switch to secondary mode in xenomai tasks

[C Smith]

How can we verify which tasks are switching to secondary mode? We know the
xml parser definitely is switching to secondary mode, setting T_WARNSW,
causing the application to send the SIGXCPU signal, but we don't know if
it's affecting the other tasks.

On Fri, Apr 6, 2018 at 10:17 AM, Greg Gallagher 
wrote:

> If a tasks switches to secondary mode it would act like a normal Linux
> thread. I haven't used Xenomai 2.6 in a while but if you are seeing
> both tasks drop to secondary mode you may want to list the resources
> that they are sharing and how you are sharing them and then we can see
> if something would cause mode switches. Are you seeing both threads
> drop to secondary mode?
>
> -Greg
>
> On Fri, Apr 6, 2018 at 1:01 PM, C Smith  wrote:
> > The tasks manipulate shared data however they do not communicate
> directly.
> > The rt_task which parses the xml document and the main rt_task are
> running
> > periodically at different rates using rt_task_set_periodic.
> >
> > On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher 
> > wrote:
> >>
> >> Do the tasks communicate with each other?
> >>
> >> -Greg
> >>
> >> On Fri, Apr 6, 2018 at 12:51 PM, C Smith 
> >> wrote:
> >> > Hi all--
> >> >
> >> > Our real time application has a main rt_task which runs concurrently
> >> > with
> >> > several other rt_tasks (spawned using rt_task_create) and we are
> >> > concerned
> >> > about a context switch in one of the tasks. The problematic task uses
> >> > libxml2 to parse an xml document sent over ethernet which seems to
> cause
> >> > a
> >> > switch to secondary mode. Would this also switch the other tasks we
> are
> >> > running to secondary mode, or is it isolated?
> >> >
> >> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
> >> > ___
> >> > Xenomai mailing list
> >> > Xenomai@xenomai.org
> >> > https://xenomai.org/mailman/listinfo/xenomai
> >
> >
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PULL] ipipe 4.9 update

[Jan Kiszka]

The following changes since commit 3d21f886ffae3ffdef54a19ec53393482626a84c:

  ipipe-core-4.9.90-x86-6 (2018-03-26 17:36:13 +0200)

are available in the git repository at:

  git://git.xenomai.org/ipipe-jki 

for you to fetch changes up to 3fac4646875dbbab6969cf080a02467b578c55be:

  Merge tag 'v4.9.92' into for-upstream/4.9 (2018-04-06 18:45:31 +0200)


(excluding stable merge)
Jan Kiszka (4):
  arm/ipipe: Avoid open-coded __ipipe_call_mayday
  ipipe: Fix root domain guard in preempt_schedule_notrace
  x86/ipipe: Deny JUMP_LABEL over I-pipe
  x86/ipipe: Disable access_ok context under I-pipe

 arch/arm/kernel/ipipe.c| 3 +--
 arch/x86/Kconfig   | 2 +-
 arch/x86/include/asm/uaccess.h | 2 +-
 kernel/sched/core.c| 2 +-
 4 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/ipipe.c b/arch/arm/kernel/ipipe.c
index b95c8128c5de..e7642bd28871 100644
--- a/arch/arm/kernel/ipipe.c
+++ b/arch/arm/kernel/ipipe.c
@@ -354,8 +354,7 @@ void __ipipe_exit_irq(struct pt_regs *regs)
 * so prefer test then maybe clear over
 * test_and_clear.
 */
-   ipipe_clear_thread_flag(TIP_MAYDAY);
-   __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs);
+   __ipipe_call_mayday(regs);
}
 }
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1bc07b02..f553d85db062 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -83,7 +83,7 @@ config X86
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HARDENED_USERCOPY
select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
-   select HAVE_ARCH_JUMP_LABEL
+   select HAVE_ARCH_JUMP_LABEL if !IPIPE
select HAVE_ARCH_KASAN  if X86_64 && SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a8d85a687cf4..bffa3f09067e 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -68,7 +68,7 @@ static inline bool __chk_range_not_ok(unsigned long addr, 
unsigned long size, un
__chk_range_not_ok((unsigned long __force)(addr), size, limit); \
 })
 
-#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+#if defined(CONFIG_DEBUG_ATOMIC_SLEEP) && !defined(CONFIG_IPIPE)
 # define WARN_ON_IN_IRQ()  WARN_ON_ONCE(!in_task())
 #else
 # define WARN_ON_IN_IRQ()
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 37a9420059e3..2f781dcede7a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3582,7 +3582,7 @@ asmlinkage __visible void __sched notrace 
preempt_schedule_notrace(void)
 {
enum ctx_state prev_ctx;
 
-   if (likely(!preemptible() || !ipipe_root_p))
+   if (likely(!preemptible() || !ipipe_root_p || hard_irqs_disabled()))
return;
 
do {

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

Re: [Xenomai] Context switch to secondary mode in xenomai tasks

[Greg Gallagher]

If a tasks switches to secondary mode it would act like a normal Linux
thread. I haven't used Xenomai 2.6 in a while but if you are seeing
both tasks drop to secondary mode you may want to list the resources
that they are sharing and how you are sharing them and then we can see
if something would cause mode switches. Are you seeing both threads
drop to secondary mode?

-Greg

On Fri, Apr 6, 2018 at 1:01 PM, C Smith  wrote:
> The tasks manipulate shared data however they do not communicate directly.
> The rt_task which parses the xml document and the main rt_task are running
> periodically at different rates using rt_task_set_periodic.
>
> On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher 
> wrote:
>>
>> Do the tasks communicate with each other?
>>
>> -Greg
>>
>> On Fri, Apr 6, 2018 at 12:51 PM, C Smith 
>> wrote:
>> > Hi all--
>> >
>> > Our real time application has a main rt_task which runs concurrently
>> > with
>> > several other rt_tasks (spawned using rt_task_create) and we are
>> > concerned
>> > about a context switch in one of the tasks. The problematic task uses
>> > libxml2 to parse an xml document sent over ethernet which seems to cause
>> > a
>> > switch to secondary mode. Would this also switch the other tasks we are
>> > running to secondary mode, or is it isolated?
>> >
>> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
>> > ___
>> > Xenomai mailing list
>> > Xenomai@xenomai.org
>> > https://xenomai.org/mailman/listinfo/xenomai
>
>

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

[Xenomai] dlopen test in current stable fails

[Jan Kiszka]

Henning,

should dlopen work with stable-3.0.x? The test case is merged, but it
fails for me.

../../../lib/boilerplate/setup.c:686: __register_setup_call: Assertion
`!main_init_done' failed.

(at this chance I noticed that redirecting smokey outputs on the command
line does not work as well - different story).

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 switch to secondary mode in xenomai tasks

[C Smith]

The tasks manipulate shared data however they do not communicate directly.
The rt_task which parses the xml document and the main rt_task are running
periodically at different rates using rt_task_set_periodic.

On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher 
wrote:

> Do the tasks communicate with each other?
>
> -Greg
>
> On Fri, Apr 6, 2018 at 12:51 PM, C Smith 
> wrote:
> > Hi all--
> >
> > Our real time application has a main rt_task which runs concurrently with
> > several other rt_tasks (spawned using rt_task_create) and we are
> concerned
> > about a context switch in one of the tasks. The problematic task uses
> > libxml2 to parse an xml document sent over ethernet which seems to cause
> a
> > switch to secondary mode. Would this also switch the other tasks we are
> > running to secondary mode, or is it isolated?
> >
> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
> > ___
> > 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] Context switch to secondary mode in xenomai tasks

[Greg Gallagher]

Do the tasks communicate with each other?

-Greg

On Fri, Apr 6, 2018 at 12:51 PM, C Smith  wrote:
> Hi all--
>
> Our real time application has a main rt_task which runs concurrently with
> several other rt_tasks (spawned using rt_task_create) and we are concerned
> about a context switch in one of the tasks. The problematic task uses
> libxml2 to parse an xml document sent over ethernet which seems to cause a
> switch to secondary mode. Would this also switch the other tasks we are
> running to secondary mode, or is it isolated?
>
> We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

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

[Xenomai] Context switch to secondary mode in xenomai tasks

[C Smith]

Hi all--

Our real time application has a main rt_task which runs concurrently with
several other rt_tasks (spawned using rt_task_create) and we are concerned
about a context switch in one of the tasks. The problematic task uses
libxml2 to parse an xml document sent over ethernet which seems to cause a
switch to secondary mode. Would this also switch the other tasks we are
running to secondary mode, or is it isolated?

We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] 4.9 for x86 issue

[Jan Kiszka]

On 2018-04-05 22:13, Jan Kiszka wrote:
> 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 ]---
> 

The WARN_ON is due to missing
http://git.xenomai.org/ipipe-jki.git/commit/?h=for-upstream/4.4-update=d95805a2f3448cf65e85897cf43f260b9ff3f9d0
in 4.9. I'm preparing a PR. I've also did a stable update for 4.9.

The idleness bug can be resolved by dropping ipipe_enter_idle_hook from
Xenomai until we have a better logic at hand. If someone wants the
current behavior, there is still idle=poll.

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] 4.9 for x86 issue

[Jan Kiszka]

On 2018-04-06 17:11, Jan Kiszka wrote:
>> This is not about testing for Cobalt idleness, but for its core timer
>> idleness, given that the core timer is shared between both kernels. We
>> want to know whether we may allow the regular kernel to shutdown the
>> clock event hardware for entering a sleep state. XNIDLE -> XNTIMERIDLE
>> if you will. I covered this stuff in Documentation/ipipe.rst lately.
>>
> 
> I still don't see the problem. We own the timer, Linux does not program
> it. And letting Linux call hlt does not disturb the timer programming,
> in most cases at least (there might be some weird old broken hardware).

Looking at ipipe_enter_idle_hook more closely: What might make sense as
logic here is a test for a close-to-expire timer on the CPU. Then we
would do polling until the expiry which may reduce wakeup latencies. But
the question would be what the thresholds should be on the different
targets.

Did you see any concrete issues without that hook? On which architecture?

Jan

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

Re: [Xenomai] Context switching with POSIX skin

[rodrigo . amaducci]

Thank you very much Greg.

Quoting Greg Gallagher :


I'll look into it this weekend and see if I can get the demo running
on Zynq or one of my boards.

On Thu, Apr 5, 2018 at 9:25 AM,   wrote:

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] building Xenomai Apps with CMake (RFC)

[Leopold Palomo-Avellaneda]

Hi

On 06/04/18 11:36, Lange Norbert wrote:
[...]

> 
> Google for "FindXenomai" to see that I am hardy the only one with that need.
> What I would like is to have a proper solution for Xenomai, and my way of 
> doing that
> is to get criticized from people-in-the-know.

I have done a "FindXenomai" and I have found several projects. I did myself one,
based in the ROS one, and the Orocos people has another for instance.

You are not alone in the darkness ... ;-)


Leopold


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

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

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

[Leopold Palomo-Avellaneda]

 a cross-platform. I have used it in MacOSX, GNU/Linux and MSWindows, (of
course that can work with all the Unix flavours) so, I don't understand why are
you saying that "does not seem to be useful for Xenomai"


> And there is a zoo of such build systems out there, what about bazel,
> scons, rake ... ? So i guess i am against adding support for any such
> thing to xenomai, especially if its OS abstractions do not match --
> like it seems to be the case for CMake.

Well, I would prefer that Xenomai works with any build system ...

Leopold


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

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

Re: [Xenomai] 4.9 for x86 issue

[Jan Kiszka]

On 2018-04-06 16:11, Philippe Gerum wrote:
> On 04/06/2018 03:38 PM, Jan Kiszka wrote:
>> On 2018-04-06 08:54, Philippe Gerum wrote:
>>> On 04/05/2018 10:13 PM, Jan Kiszka wrote:
>>>> 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.
>>>>
>>>
>>> I can't reproduce this, the loadavg on my qemu instance consistently
>>> converges to 0.0x figures while running the latency test (10Khz or 1Khz,
>>> same). I'm now running 4.9.92, but I don't think this should make any
>>> difference, since I could trace the box entering the idle state on .90.
>>>
>>> Are you running the ia32emu mode, or x86_64? Also, could you share your
>>> .config for building the guest kernel?
>>
>> Config is the same I sent back then. Userland is 64-bit, compat support
>> enabled.
> 
> You only sent me the CONFIG_IDLE* settings I asked for. I'd need the
> whole file now.

Sorry, though I did. Attached.

> 
>>
>> The reason I see so far: xnclock_core_local_shot never sets XNIDLE.
> 
> It does here (I traced it). However this should depend on the NO_HZ
> settings, mine are :
> 
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> CONFIG_NO_HZ=y
> 

Same here.

>> I
>> suspect we always have a timer registered, that for the host clock. So
> 
> In that case, the timer is not idle Xenomai-wise.
> 
>> we can't become idle this way. I'm not even sure that this test makes
>> sense because a pending RT timer does not make a non-idle system.
>>
> 
> This is not about testing for Cobalt idleness, but for its core timer
> idleness, given that the core timer is shared between both kernels. We
> want to know whether we may allow the regular kernel to shutdown the
> clock event hardware for entering a sleep state. XNIDLE -> XNTIMERIDLE
> if you will. I covered this stuff in Documentation/ipipe.rst lately.
> 

I still don't see the problem. We own the timer, Linux does not program
it. And letting Linux call hlt does not disturb the timer programming,
in most cases at least (there might be some weird old broken hardware).

Jan
-- next part --
A non-text attachment was scrubbed...
Name: .config.xz
Type: application/x-xz
Size: 21268 bytes
Desc: not available
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20180406/32e24aae/attachment.bin>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] LDFLAGS/LDLIBS in makefile

[Giulio Moro]

This is about best practices.
The GNU Make manual says  
(https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html)
> LDFLAGS
> Extra flags to give to compilers when they are supposed to invoke the linker, 
> ‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable 
> instead.

> LDLIBS
> Library flags or names given to compilers when they are supposed to invoke 
> the linker, ‘ld’. LOADLIBES is a deprecated (but still supported) alternative 
> to LDLIBS. Non-library linker flags, such as -L, should go in the LDFLAGS 
> variable.

When calling, e.g.:  
`xeno-config --skin cobalt --ldflags --no-auto-init`
you get 
-Wl,--no-as-needed -Wl,@/usr/xenomai/lib/modechk.wrappers-L/usr/xenomai/lib 
-lcobalt -lmodechk -lpthread -lrt

So according to the Make manual, this should be split in 
LDFLAGS=-Wl,--no-as-needed -Wl,@/usr/xenomai/lib/modechk.wrappers
-L/usr/xenomai/lib 
LDLIBS=-lcobalt -lmodechk -lpthread -lrt

How do you deal with this in practical life? I tend to have everything into 
`LDLIBS`: even though it does not follow the manual, it works. I guess there 
are only a small number of cases in which not following the manual actually 
causes troubles.  Did you encounter any when working with Xenomai? How do you 
handle the list of options generated by xeno-config ?

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

Re: [Xenomai] 4.9 for x86 issue

[Philippe Gerum]

On 04/06/2018 03:38 PM, Jan Kiszka wrote:
> On 2018-04-06 08:54, Philippe Gerum wrote:
>> On 04/05/2018 10:13 PM, Jan Kiszka wrote:
>>> 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.
>>>
>>
>> I can't reproduce this, the loadavg on my qemu instance consistently
>> converges to 0.0x figures while running the latency test (10Khz or 1Khz,
>> same). I'm now running 4.9.92, but I don't think this should make any
>> difference, since I could trace the box entering the idle state on .90.
>>
>> Are you running the ia32emu mode, or x86_64? Also, could you share your
>> .config for building the guest kernel?
> 
> Config is the same I sent back then. Userland is 64-bit, compat support
> enabled.

You only sent me the CONFIG_IDLE* settings I asked for. I'd need the
whole file now.

> 
> The reason I see so far: xnclock_core_local_shot never sets XNIDLE.

It does here (I traced it). However this should depend on the NO_HZ
settings, mine are :

CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y

> I
> suspect we always have a timer registered, that for the host clock. So

In that case, the timer is not idle Xenomai-wise.

> we can't become idle this way. I'm not even sure that this test makes
> sense because a pending RT timer does not make a non-idle system.
> 

This is not about testing for Cobalt idleness, but for its core timer
idleness, given that the core timer is shared between both kernels. We
want to know whether we may allow the regular kernel to shutdown the
clock event hardware for entering a sleep state. XNIDLE -> XNTIMERIDLE
if you will. I covered this stuff in Documentation/ipipe.rst lately.

-- 
Philippe.

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

Re: [Xenomai] Context switching with POSIX skin

[Greg Gallagher]

I'll look into it this weekend and see if I can get the demo running
on Zynq or one of my boards.

On Thu, Apr 5, 2018 at 9:25 AM,   wrote:
> 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] 4.9 for x86 issue

[Jan Kiszka]

On 2018-04-06 08:54, Philippe Gerum wrote:
> On 04/05/2018 10:13 PM, Jan Kiszka wrote:
>> 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.
>>
> 
> I can't reproduce this, the loadavg on my qemu instance consistently
> converges to 0.0x figures while running the latency test (10Khz or 1Khz,
> same). I'm now running 4.9.92, but I don't think this should make any
> difference, since I could trace the box entering the idle state on .90.
> 
> Are you running the ia32emu mode, or x86_64? Also, could you share your
> .config for building the guest kernel?

Config is the same I sent back then. Userland is 64-bit, compat support
enabled.

The reason I see so far: xnclock_core_local_shot never sets XNIDLE. I
suspect we always have a timer registered, that for the host clock. So
we can't become idle this way. I'm not even sure that this test makes
sense because a pending RT timer does not make a non-idle system.

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] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

 >-Original Message-
 >From: Henning Schild [mailto:henning.sch...@siemens.com]
 >Sent: Freitag, 06. April 2018 10:47
 >To: Lange Norbert
 >Cc: Jan Kiszka; Xenomai (xenomai@xenomai.org)
 >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.
 >
 >
 >Am Thu, 5 Apr 2018 15:54:34 +
 >schrieb 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)
 >
 >No, i do not know anyone using CMake with Xenomai, so i would not know
 >how to deal with bootstrap there.

This question was not limited to CMake, but I am curious whether the bootstrap 
magic
from the tools shipping with Xenomai is popular outside of it.

 >
 >>  >
 >>  >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.
 >
 >It would probably be a good idea to try and mainline it in one of the
 >two projects. And my guess is that CMake would not really fit and they
 >might not want such code.

Well, there are multiple Linux-only modules already (FindLTTngUST, FindX11),
aswell as "non-OS" compilers like IAR.
I doubt they would be happy if I add some bootstrap code for Xenomai though.

https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html

 >
 >> 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.
 >
 >I did not fully understand the bootstrap with regard to cmake yet. But
 >the magic wrapping is not pretty, also in other regards. So patches
 >that improve that, while actually targeting something like CMake, would
 >be welcome.

There is no bootstrap with CMake yet, and I am unsure whether the current
method should be supported at all.
The cost of adding the bootstrap code to a *new* project is low, and even lower
If this would be distributed as header with Xenomai (Again that would not be 
limited to CMake). You of course
lose the ability to compile sources as-is (which I believe was the motivation)

My plan would be to allow applications/libraries an easy way of creating their 
own bootstrap code.
2 variants of this:

bootstrap-wrap.c:

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

[Henning Schild]

Am Thu, 5 Apr 2018 15:54:34 +
schrieb 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)

No, i do not know anyone using CMake with Xenomai, so i would not know
how to deal with bootstrap there.

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

It would probably be a good idea to try and mainline it in one of the
two projects. And my guess is that CMake would not really fit and they
might not want such code.

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

I did not fully understand the bootstrap with regard to cmake yet. But
the magic wrapping is not pretty, also in other regards. So patches
that improve that, while actually targeting something like CMake, would
be welcome.

Now regarding CMake itself. Is not one of its main purposes to be
platform independant, that does not seem to be too useful for Xenomai.
And there is a zoo of such build systems out there, what about bazel,
scons, rake ... ? So i guess i am against adding support for any such
thing to xenomai, especially if its OS abstractions do not match --
like it seems to be the case for CMake.

Henning

> 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

Re: [Xenomai] 4.9 for x86 issue

[Philippe Gerum]

On 04/05/2018 10:13 PM, Jan Kiszka wrote:
> 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.
> 

I can't reproduce this, the loadavg on my qemu instance consistently
converges to 0.0x figures while running the latency test (10Khz or 1Khz,
same). I'm now running 4.9.92, but I don't think this should make any
difference, since I could trace the box entering the idle state on .90.

Are you running the ia32emu mode, or x86_64? Also, could you share your
.config for building the guest kernel?

Thanks,

-- 
Philippe.

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