Re: [Xenomai] 4.9 for x86 issue
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
Re: [Xenomai] 4.9 for x86 issue
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)
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()
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()
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)
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()
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
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
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
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
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
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
