[Xenomai] Some Problem with build sam5d36 IMAGE
./prepare-kernel.sh --arch=arm --adeos=/usr/src/linux/ipipe-core-4.14.36-arm-1.patch --linux=/usr/src/linux/linux-4.14.36 make menuconfig and I load file in /usr/src/linux/linux-4.14.36/arch/arm/configs/sama5_defconfig --and save in /usr/src/linux/linux-4.14.36/.config make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- bzImage modules That's all I do, while building, some errors coming that : AS arch/arm/xenomai/switch.o CC arch/arm/xenomai/syscall.o In file included from arch/arm/xenomai/include/asm/xenomai/syscall.h:29:0, from arch/arm/xenomai/syscall.c:22: ./include/asm-generic/xenomai/syscall.h: In function 'cobalt_copy_from_user': ./include/asm-generic/xenomai/syscall.h:49:3: error: implicit declaration of function '__copy_from_user_inatomic' [-Werror=implicit-function-declaration] __xn_copy_from_user(dst, src, size)) ? -EFAULT : 0; ^ ./include/asm-generic/xenomai/syscall.h: In function 'cobalt_copy_to_user': ./include/asm-generic/xenomai/syscall.h:56:3: error: implicit declaration of function '__copy_to_user_inatomic' [-Werror=implicit-function-declaration] __xn_copy_to_user(dst, src, size)) ? -EFAULT : 0; ^ cc1: some warnings being treated as errors scripts/Makefile.build:328: recipe for target 'arch/arm/xenomai/syscall.o' failed make[1]: *** [arch/arm/xenomai/syscall.o] Error 1 Makefile:1040: recipe for target 'arch/arm/xenomai' failed make: *** [arch/arm/xenomai] Error 2 Can any body help me ? ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai 3.0.7
On 06/27/2018 08:54 PM, Jeff Melvile wrote:
> Philippe,
>
> Thanks again for all your work on this release.
>
> On Mon, 25 Jun 2018, Philippe Gerum wrote:
>
>>
>> Xenomai 3.0.7 is out [1]. The GIT repository can be cloned from [2].
>>
>> Some GPIO driver updates, several bug fixes in the Cobalt core, and a
>> critical bug removed from the pshared heap (for users of non-POSIX APIs
>> building with --enable-pshared).
>>
>> An effort to sanitize some legacy from RTnet causing invalid accesses
>> from kernel space to userland memory also stands out, although more work
>> remains in this area.
>>
>> This release supports up to the Linux 4.14 series for ARM, ARM64 and
>> PPC32. Work is still ahead for running Cobalt over 4.14/x86 though.
>
> Is ARM64 a typo? The v3.0.7 tag doesn't have ARM64 directories in
> {kernel,lib}/cobalt/arch
>
Yes, ARM64 is supported over Xenomai's -next branch only. I-pipe/4.14
does support ARM64 already though.
--
Philippe.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai 3.0.7
Philippe,
Thanks again for all your work on this release.
On Mon, 25 Jun 2018, Philippe Gerum wrote:
>
> Xenomai 3.0.7 is out [1]. The GIT repository can be cloned from [2].
>
> Some GPIO driver updates, several bug fixes in the Cobalt core, and a
> critical bug removed from the pshared heap (for users of non-POSIX APIs
> building with --enable-pshared).
>
> An effort to sanitize some legacy from RTnet causing invalid accesses
> from kernel space to userland memory also stands out, although more work
> remains in this area.
>
> This release supports up to the Linux 4.14 series for ARM, ARM64 and
> PPC32. Work is still ahead for running Cobalt over 4.14/x86 though.
Is ARM64 a typo? The v3.0.7 tag doesn't have ARM64 directories in
{kernel,lib}/cobalt/arch
>
> [1] http://xenomai.org/downloads/xenomai/stable/latest/
> [2] https://git.xenomai.org/xenomai/
>
> --
> Philippe.
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>
Thanks,
Jeff
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On 06/27/2018 07:29 PM, Pintu Kumar wrote: > On Wed, Jun 27, 2018 at 10:47 PM Greg Gallagher wrote: >> >> I don't think Beaglebone is supported currently in RTNet. >> > > But I am just checking loopback interface with 127.0.0.1 > I hope that should work on all boards and arch, even without > installing the net driver. > You must be the first and only user giving any feedback about rtnet over ARM if my memory serves me well. So either all others have been hiding behind for all these years, or you may be the only specimen of that species. FWIW, all of my rtnet fixes that went in since 3.0.6 have been tested on x86 exclusively. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On 06/27/2018 06:17 PM, Jan Kiszka wrote: > On 2018-06-27 16:12, Pintu Kumar wrote: >>> With nosmap, that particular issue should no longer occur (at least as >>> long as we can ask the kernel for this relaxation), so I suspect the >>> other effect you see now is something else. >> >> Just for the information, that issue occurred even on Beagle bone, and >> there is no smap on arm. >> However, it works on virtual box. how ? > > Does it work when you go back to Xenomai 3.0.6? Then it would be a > regression of the copy-to/from-userspace improvements done after that > release, you could start bisecting which commit introduced it. > > But I'm not sure right now if there isn't something similar to smap > (then just without a knob to turn it off) in the ARM architecture as well... > AFAIR, use of protection domains is built in depending on a selection by the CPU support code. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai Meetup at Embedded Linux Conference Europe
Hi, I am also planning to submit a talk at ELC-E about Xenomai and my pratical experience. However it should be approved first and funded by my company. If everything goes well, then I will be also interested in this meetup at ELC-E. Thanks, Pintu On Wed, Jun 27, 2018 at 3:39 PM Jan Kiszka wrote: > > Hi all, > > ELC-E is coming, October 22-24 in Edinburgh, and I've received some > indications that there is interest in having another meetup of the > community. The question is now how broad that interest is and what form > we should head for. > > Options: > - BoF at ELC-E (1h, evening session): > - brief update from the project > - open discussion about user requirements, to-dos, contributions, > etc. > - mini-summit at ELC-E (3-4 hours, but I'm concerned we won't get that >slot) > - project update > - user presentations > - BoF session(s) > - separate meetup in a venue nearby (half day as well) > - [same as mini-summit] > > Please drop a note if you are interested and in what form/topics, either > here on the list or privately. I need to decide by July 1 if and how we > should apply for a slot at ELC-E. > > Cheers, > 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On Wed, Jun 27, 2018 at 10:47 PM Greg Gallagher wrote: > > I don't think Beaglebone is supported currently in RTNet. > But I am just checking loopback interface with 127.0.0.1 I hope that should work on all boards and arch, even without installing the net driver. > On Wed, Jun 27, 2018 at 1:13 PM, Pintu Kumar wrote: > > On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka wrote: > >> > >> On 2018-06-27 16:12, Pintu Kumar wrote: > >> >> With nosmap, that particular issue should no longer occur (at least as > >> >> long as we can ask the kernel for this relaxation), so I suspect the > >> >> other effect you see now is something else. > >> > > >> > Just for the information, that issue occurred even on Beagle bone, and > >> > there is no smap on arm. > >> > However, it works on virtual box. how ? > >> > >> Does it work when you go back to Xenomai 3.0.6? Then it would be a > >> regression of the copy-to/from-userspace improvements done after that > >> release, you could start bisecting which commit introduced it. > >> > > > > Nope, I never had success with rtnet on arm architecture (mainly > > beagle bone), even with the old 3.0.6. > > At least earlier, on x86_64 (SkyLake), I saw the loopback part working > > with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet > > fixes) and with "nosmap" in commandline. > > > > But now it looks like the situation becomes more worse. > > I will have to freshly look into it, but since I use prepare_kernel to > > apply as single patch, it might be painful to bisect it. > > Will try to find the root cause though > > > > Hoping for the best... > > > >> But I'm not sure right now if there isn't something similar to smap > >> (then just without a knob to turn it off) in the ARM architecture as > >> well... > >> > >> 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] KERNEL OOPS : hikey620: arm64 - while xecuting xeno-test
This is hikey620 board from hisilicon with 8 cores. Currently we have resolved this issue by disabling: ACPI, CPU_IDLE, but enabling CPU_FREQ and changing default CPU governor to userspace. On Wed, Jun 27, 2018 at 10:31 PM Greg Gallagher wrote: > > This is an ipipe issue. CPU4 seems to be stalled or starved. I'm > doing some RPI3 testing and I haven't seen this yet. Which board is > this? Is it from 96boards with the octacore A53? > > -Greg > > On Tue, Jun 26, 2018 at 7:56 AM, Pintu Kumar wrote: > > Dear Greg/Philippe, > > > > I am running xeno-test on hikey620, with following details: > > - Kernel version: 4.9.51 > > - ipipe: ipipe-core-4.9.51-arm64-4.patch > > - xenomai-3 : next branch > > - xenomai-3 commit until: scripts/prepare-kernel.sh: drop left overs > > from obsolete ports > > - version: 3.1-devel > > > > Build xenomai next using the following: > > # ./scripts/bootstrap > > # ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls > > --enable-dlopen-libs > > # make -j8 > > # make install > > > > => Enabled CONFIGS related to xeno-test in kernel: > > CONFIG_XENO_DRIVERS_RTIPC_BUFP CONFIG_XENO_OPT_BUFP_NRPORT=32 > > CONFIG_XENO_DRIVERS_RTIPC_IDDP > > CONFIG_XENO_OPT_IDDP_NRPORT=32 > > CONFIG_XENO_DRIVERS_RTDMTEST=m > > CONFIG_XENO_OPT_SCHED_TP > > CONFIG_XENO_OPT_SCHED_TP_NRPART=4 > > CONFIG_XENO_DRIVERS_RTIPC_XDDP > > > > The run xeno-test: > > # /usr/xenomai/bin/xeno-test > > > > Some tests passed, but after sometime during smokey test, we get this > > back trace in kernel: > > > > If you have any pointers regarding this issue, please let me know. > > > > Thanks, > > Pintu > > === > > [ 487.848376] INFO: rcu_preempt self-detected stall on CPU[ > > 487.848446] systemd[1]: systemd-journald.service: Main process exited, > > code=killed > > , status=6/ABRT > > [ 487.848497] INFO: rcu_preempt self-detected stall on CPU > > [ 487.848506] 6-...: (1 GPs behind) idle=99d/1/0 softirq=1452/1452 fqs=0 > > [ 487.848508] > > [ 487.848513] (t=29983 jiffies g=391 c=390 q=319) > > [ 487.848519] rcu_preempt kthread starved for 29983 jiffies! g391 > > c390 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 > > [ 487.848523] rcu_preempt S > > [ 487.848527] 0 7 2 0x > > Call trace: > > [ 487.848548] [] __switch_to+0x8c/0xa0 > > [ 487.848558] [] __schedule+0x1a8/0x5e8 > > [ 487.848563] [] schedule+0x3c/0xa8 > > [ 487.848569] [] schedule_timeout+0x128/0x280 > > [ 487.848576] [] rcu_gp_kthread+0x4dc/0x798 > > [ 487.848582] [] kthread+0xe0/0xf8 > > [ 487.848587] [] ret_from_fork+0x14/0x30 > > [ 487.848598] Task dump for CPU 3: > > [ 487.848600] systemd-logind R > > [ 487.848602] running task0 2294 1 0x0200 > > Call trace: > > [ 487.848611] [] __switch_to+0x8c/0xa0 > > [ 487.848617] [] __sys_recvmsg+0x40/0x80 > > [ 487.848621] [] 0x8000318b2648 > > [ 487.848623] Task dump for CPU 4: > > [ 487.848625] swapper/4 R > > [ 487.848627] running task0 0 1 0x0002 > > Call trace: > > [ 487.848635] [] __switch_to+0x8c/0xa0 > > [ 487.848638] [] 0x80003311c200 > > [ 487.848640] Task dump for CPU 6: > > [ 487.848642] swapper/6 R > > [ 487.848643] running task0 0 1 0x > > Call trace: > > [ 487.848653] [] dump_backtrace+0x0/0x1b0 > > [ 487.848659] [] show_stack+0x14/0x20 > > [ 487.848665] [] sched_show_task+0xa0/0xf8 > > [ 487.848670] [] dump_cpu_task+0x40/0x50 > > [ 487.848676] [] rcu_dump_cpu_stacks+0xb4/0xe8 > > [ 487.848682] [] rcu_check_callbacks+0x810/0x9e0 > > [ 487.848688] [] update_process_times+0x34/0x60 > > [ 487.848693] [] update_root_process_times+0x48/0x58 > > [ 487.848700] [] tick_sched_handle.isra.4+0x5c/0x70 > > [ 487.848705] [] tick_sched_timer+0x44/0x90 > > [ 487.848710] [] __hrtimer_run_queues+0xec/0x170 > > [ 487.848715] [] hrtimer_interrupt+0xa0/0x1d8 > > [ 487.848720] [] tick_receive_broadcast+0x28/0x48 > > [ 487.848726] [] handle_IPI+0xa4/0x140 > > [ 487.848730] [] __ipipe_do_IPI+0x20/0x28 > > [ 487.848735] [] __ipipe_do_sync_stage+0x1ac/0x1d0 > > [ 487.848739] [] ipipe_unstall_root+0x44/0x50 > > [ 487.848745] [] cpuidle_enter_state+0x154/0x220 > > [ 487.848749] [] cpuidle_enter+0x18/0x20 > > [ 487.848754] [] call_cpuidle+0x44/0x88 > > [ 487.848759] [] cpu_startup_entry+0x190/0x1e8 > > [ 487.848763] [] secondary_start_kernel+0x164/0x1a0 > > [ 487.848766] [<009681a4>] 0x9681a4 > > [ 487.849172] systemd[1]: systemd-journald.service: Unit entered failed > > state. > > [ 487.849674] systemd[1]: systemd-journald.service: Failed with > > result 'signal'. > > [ 487.851292] systemd[1]: systemd-journald.service: Service has no > > hold-off time, scheduling restart. > > [ 487.852621] systemd[1]: Stopped Flush Journal to Persistent Storage. > > [ 487.852792] systemd[1]: Stopping Flush Journal to Persistent Storage... > > [ 487.852838] systemd[1]: Stopped Journal Service. > > [ 487.854881]
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
I don't think Beaglebone is supported currently in RTNet. On Wed, Jun 27, 2018 at 1:13 PM, Pintu Kumar wrote: > On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka wrote: >> >> On 2018-06-27 16:12, Pintu Kumar wrote: >> >> With nosmap, that particular issue should no longer occur (at least as >> >> long as we can ask the kernel for this relaxation), so I suspect the >> >> other effect you see now is something else. >> > >> > Just for the information, that issue occurred even on Beagle bone, and >> > there is no smap on arm. >> > However, it works on virtual box. how ? >> >> Does it work when you go back to Xenomai 3.0.6? Then it would be a >> regression of the copy-to/from-userspace improvements done after that >> release, you could start bisecting which commit introduced it. >> > > Nope, I never had success with rtnet on arm architecture (mainly > beagle bone), even with the old 3.0.6. > At least earlier, on x86_64 (SkyLake), I saw the loopback part working > with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet > fixes) and with "nosmap" in commandline. > > But now it looks like the situation becomes more worse. > I will have to freshly look into it, but since I use prepare_kernel to > apply as single patch, it might be painful to bisect it. > Will try to find the root cause though > > Hoping for the best... > >> But I'm not sure right now if there isn't something similar to smap >> (then just without a knob to turn it off) in the ARM architecture as well... >> >> 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka wrote: > > On 2018-06-27 16:12, Pintu Kumar wrote: > >> With nosmap, that particular issue should no longer occur (at least as > >> long as we can ask the kernel for this relaxation), so I suspect the > >> other effect you see now is something else. > > > > Just for the information, that issue occurred even on Beagle bone, and > > there is no smap on arm. > > However, it works on virtual box. how ? > > Does it work when you go back to Xenomai 3.0.6? Then it would be a > regression of the copy-to/from-userspace improvements done after that > release, you could start bisecting which commit introduced it. > Nope, I never had success with rtnet on arm architecture (mainly beagle bone), even with the old 3.0.6. At least earlier, on x86_64 (SkyLake), I saw the loopback part working with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet fixes) and with "nosmap" in commandline. But now it looks like the situation becomes more worse. I will have to freshly look into it, but since I use prepare_kernel to apply as single patch, it might be painful to bisect it. Will try to find the root cause though Hoping for the best... > But I'm not sure right now if there isn't something similar to smap > (then just without a knob to turn it off) in the ARM architecture as well... > > 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] KERNEL OOPS : hikey620: arm64 - while xecuting xeno-test
This is an ipipe issue. CPU4 seems to be stalled or starved. I'm doing some RPI3 testing and I haven't seen this yet. Which board is this? Is it from 96boards with the octacore A53? -Greg On Tue, Jun 26, 2018 at 7:56 AM, Pintu Kumar wrote: > Dear Greg/Philippe, > > I am running xeno-test on hikey620, with following details: > - Kernel version: 4.9.51 > - ipipe: ipipe-core-4.9.51-arm64-4.patch > - xenomai-3 : next branch > - xenomai-3 commit until: scripts/prepare-kernel.sh: drop left overs > from obsolete ports > - version: 3.1-devel > > Build xenomai next using the following: > # ./scripts/bootstrap > # ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls > --enable-dlopen-libs > # make -j8 > # make install > > => Enabled CONFIGS related to xeno-test in kernel: > CONFIG_XENO_DRIVERS_RTIPC_BUFP CONFIG_XENO_OPT_BUFP_NRPORT=32 > CONFIG_XENO_DRIVERS_RTIPC_IDDP > CONFIG_XENO_OPT_IDDP_NRPORT=32 > CONFIG_XENO_DRIVERS_RTDMTEST=m > CONFIG_XENO_OPT_SCHED_TP > CONFIG_XENO_OPT_SCHED_TP_NRPART=4 > CONFIG_XENO_DRIVERS_RTIPC_XDDP > > The run xeno-test: > # /usr/xenomai/bin/xeno-test > > Some tests passed, but after sometime during smokey test, we get this > back trace in kernel: > > If you have any pointers regarding this issue, please let me know. > > Thanks, > Pintu > === > [ 487.848376] INFO: rcu_preempt self-detected stall on CPU[ > 487.848446] systemd[1]: systemd-journald.service: Main process exited, > code=killed > , status=6/ABRT > [ 487.848497] INFO: rcu_preempt self-detected stall on CPU > [ 487.848506] 6-...: (1 GPs behind) idle=99d/1/0 softirq=1452/1452 fqs=0 > [ 487.848508] > [ 487.848513] (t=29983 jiffies g=391 c=390 q=319) > [ 487.848519] rcu_preempt kthread starved for 29983 jiffies! g391 > c390 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 > [ 487.848523] rcu_preempt S > [ 487.848527] 0 7 2 0x > Call trace: > [ 487.848548] [] __switch_to+0x8c/0xa0 > [ 487.848558] [] __schedule+0x1a8/0x5e8 > [ 487.848563] [] schedule+0x3c/0xa8 > [ 487.848569] [] schedule_timeout+0x128/0x280 > [ 487.848576] [] rcu_gp_kthread+0x4dc/0x798 > [ 487.848582] [] kthread+0xe0/0xf8 > [ 487.848587] [] ret_from_fork+0x14/0x30 > [ 487.848598] Task dump for CPU 3: > [ 487.848600] systemd-logind R > [ 487.848602] running task0 2294 1 0x0200 > Call trace: > [ 487.848611] [] __switch_to+0x8c/0xa0 > [ 487.848617] [] __sys_recvmsg+0x40/0x80 > [ 487.848621] [] 0x8000318b2648 > [ 487.848623] Task dump for CPU 4: > [ 487.848625] swapper/4 R > [ 487.848627] running task0 0 1 0x0002 > Call trace: > [ 487.848635] [] __switch_to+0x8c/0xa0 > [ 487.848638] [] 0x80003311c200 > [ 487.848640] Task dump for CPU 6: > [ 487.848642] swapper/6 R > [ 487.848643] running task0 0 1 0x > Call trace: > [ 487.848653] [] dump_backtrace+0x0/0x1b0 > [ 487.848659] [] show_stack+0x14/0x20 > [ 487.848665] [] sched_show_task+0xa0/0xf8 > [ 487.848670] [] dump_cpu_task+0x40/0x50 > [ 487.848676] [] rcu_dump_cpu_stacks+0xb4/0xe8 > [ 487.848682] [] rcu_check_callbacks+0x810/0x9e0 > [ 487.848688] [] update_process_times+0x34/0x60 > [ 487.848693] [] update_root_process_times+0x48/0x58 > [ 487.848700] [] tick_sched_handle.isra.4+0x5c/0x70 > [ 487.848705] [] tick_sched_timer+0x44/0x90 > [ 487.848710] [] __hrtimer_run_queues+0xec/0x170 > [ 487.848715] [] hrtimer_interrupt+0xa0/0x1d8 > [ 487.848720] [] tick_receive_broadcast+0x28/0x48 > [ 487.848726] [] handle_IPI+0xa4/0x140 > [ 487.848730] [] __ipipe_do_IPI+0x20/0x28 > [ 487.848735] [] __ipipe_do_sync_stage+0x1ac/0x1d0 > [ 487.848739] [] ipipe_unstall_root+0x44/0x50 > [ 487.848745] [] cpuidle_enter_state+0x154/0x220 > [ 487.848749] [] cpuidle_enter+0x18/0x20 > [ 487.848754] [] call_cpuidle+0x44/0x88 > [ 487.848759] [] cpu_startup_entry+0x190/0x1e8 > [ 487.848763] [] secondary_start_kernel+0x164/0x1a0 > [ 487.848766] [<009681a4>] 0x9681a4 > [ 487.849172] systemd[1]: systemd-journald.service: Unit entered failed > state. > [ 487.849674] systemd[1]: systemd-journald.service: Failed with > result 'signal'. > [ 487.851292] systemd[1]: systemd-journald.service: Service has no > hold-off time, scheduling restart. > [ 487.852621] systemd[1]: Stopped Flush Journal to Persistent Storage. > [ 487.852792] systemd[1]: Stopping Flush Journal to Persistent Storage... > [ 487.852838] systemd[1]: Stopped Journal Service. > [ 487.854881] systemd[1]: Starting Journal Service... > [ 487.862458] systemd-journald[2553]: File > /run/log/journal/7ed7bca1519a40c9b60c6577cb9072c1/system.journal > corrupted or uncleanly shut down, r > enaming and replacing. > [ 487.872215] systemd[1]: Started Journal Service. > [ 488.193484] 4-...: (2 GPs behind) idle=4b5/1/0 softirq=933/938 fqs=1 > [ 488.24] (t=29983 jiffies g=391 c=390 q=877) > [ 488.204710] Task dump for CPU 4: > [ 488.207931] swapper/4 R
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On 2018-06-27 16:12, Pintu Kumar wrote: >> With nosmap, that particular issue should no longer occur (at least as >> long as we can ask the kernel for this relaxation), so I suspect the >> other effect you see now is something else. > > Just for the information, that issue occurred even on Beagle bone, and > there is no smap on arm. > However, it works on virtual box. how ? Does it work when you go back to Xenomai 3.0.6? Then it would be a regression of the copy-to/from-userspace improvements done after that release, you could start bisecting which commit introduced it. But I'm not sure right now if there isn't something similar to smap (then just without a knob to turn it off) in the ARM architecture as well... 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] with/without RTmac to the RTnet
On 2018-06-27 17:32, gengdongjiu wrote: > Hi, > > Sorry to disturb you, I want to consult with you two questions: > > 1. For the RTnet, do you usually using the witout-RTmac mode or > with-RTmac mode? From the spec and code, it seems the RTmac is very > complex and reduce the real-time. RTmac was primarily designed for colliding networks, i.e. hub-based infrastructure. If you know your network load and all your applications on the network behave (no transmission bursts), you do not need RTmac (+TDMA). > > 2. Does the default Xenomai driver supports intel I210 network > card ? > That should be the rt_igb IIRC, or rt_e1000e. Give it a try (or compare PCI IDs in advance). 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] Migrating some kernel code from Xenomai 2.6 to 3.0
On 06/27/2018 05:30 PM, Radu Rendec wrote: > On Wed, Jun 27, 2018 at 10:55 AM Philippe Gerum wrote: >> The only API available from kernel space is RTDM. Since you already have >> a RTDM driver in place, all you need to do is to expose a read() or >> ioctl() service to userland, which would wait on rtdm_sem_down to be >> posted by your IRQ handler via rtdm_sem_up. > > Thanks for the detailed answer, Philippe! This should be enough to get > me going. > > On the other hand, the same semaphore is sometimes posted from user > space and that complicates things (I guess I would have to create > another ioctl() that posts the semaphore from kernel space). > That should not amount for a lot of additional kernel code. API-wise, you could also use read/write pairs to pend/post the sema4 instead of ioctls. > Since the project is on a tight schedule, I'm also considering leaving > the code on Xenomai 2.6 for now. So here's another question: is there > any chance Xenomai 2.6 could work on kernel 4.4? How about ipipe-core? > That support won't happen in mainline, 2.6 is EOL. The changes involved in supporting this on your end should amount to update Xenomai 2.6 for building over newer kernels. This may or may not be easy depending on the arch (x86 is unlikely to be that simple). The legacy I-pipe API is still there in 4.4 and 4.9 patch series, dropped by 4.14 though. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] with/without RTmac to the RTnet
Hi, Sorry to disturb you, I want to consult with you two questions: 1. For the RTnet, do you usually using the witout-RTmac mode or with-RTmac mode? From the spec and code, it seems the RTmac is very complex and reduce the real-time. 2. Does the default Xenomai driver supports intel I210 network card? Thanks! Look forward to your reply. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0
On Wed, Jun 27, 2018 at 10:55 AM Philippe Gerum wrote: > The only API available from kernel space is RTDM. Since you already have > a RTDM driver in place, all you need to do is to expose a read() or > ioctl() service to userland, which would wait on rtdm_sem_down to be > posted by your IRQ handler via rtdm_sem_up. Thanks for the detailed answer, Philippe! This should be enough to get me going. On the other hand, the same semaphore is sometimes posted from user space and that complicates things (I guess I would have to create another ioctl() that posts the semaphore from kernel space). Since the project is on a tight schedule, I'm also considering leaving the code on Xenomai 2.6 for now. So here's another question: is there any chance Xenomai 2.6 could work on kernel 4.4? How about ipipe-core? It looks like Xenomai 2.6 requires the "legacy" API of ipipe-core and that doesn't seem to compile on kernel 4.4. Thanks, Radu ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0
On 06/27/2018 03:52 PM, Radu Rendec wrote:
> Hi all,
>
> I need to port some kernel and application code from Xenomai 2.6 to
> Xenomai 3.0.
>
> The existing code creates a semaphore with sem_open() from the *kernel*
> module init function and posts it with sem_post() from a rtdm interrupt
> handler (which is also part of the kernel module). The application opens
> the same semaphore and synchronizes on it using sem_wait().
>
> I can see that the xenomai/posix/posix.h header is gone from the kernel
> tree. What is the correct way of accessing the semaphore from the kernel
> code? What headers need to be included?
>
The only API available from kernel space is RTDM. Since you already have
a RTDM driver in place, all you need to do is to expose a read() or
ioctl() service to userland, which would wait on rtdm_sem_down to be
posted by your IRQ handler via rtdm_sem_up.
The naming part would be solved by opening that particular (named)
device your RTDM driver would create.
e.g. depending on your choice on the kernel side, you would have
something like this in userland:
fd = open("/dev/rtdm/your-device", O_RDWR);
...
ret = read(fd, ...);
OR,
ret = ioctl(fd, ...);
select() could be made available in both cases too.
> The migration guide focuses more on the application side, but doesn't
> provide much info for the kernel side. By the way, the old link to the
> guide at https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ seems
> to be broken after the gitlab migration.
>
Fixed, thanks.
--
Philippe.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
I'm not that familiar with autotools (still learning), but I removed this from configure.ac : diff --git a/configure.ac b/configure.ac index 4f9b1f9..a84dd14 100644 --- a/configure.ac +++ b/configure.ac @@ -881,7 +881,6 @@ AC_CONFIG_FILES([ \ testsuite/spitest/Makefile \ testsuite/smokey/Makefile \ testsuite/smokey/arith/Makefile \ - testsuite/smokey/dlopen/Makefile \ testsuite/smokey/sched-quota/Makefile \ testsuite/smokey/sched-tp/Makefile \ testsuite/smokey/setsched/Makefile \ And I don't see the dlopen tests being built. This may get you past the test failing for now. I'll add to the to do llist to test this with the latest version of the stable branch. -Greg On Wed, Jun 27, 2018 at 9:21 AM, Pintu Kumar wrote: > Hi, > > Sorry, but both the below patches are already applied to my xenomai-next repo: > build: link dlopen libs with "nodelete" > smokey/dlopen: fix testcase > > Still I am facing dlopen issue. > Is there any other patches I am missing? > > > Thanks, > Pintu > > On Wed, Jun 27, 2018 at 6:47 PM Pintu Kumar wrote: >> >> Hi, >> >> One doubt, how do we clone 3.0.7 ? >> Is it part of the following branches? >> remotes/origin/next >> remotes/origin/stable/v3.0.x >> >> I could not find any branch with the name 3.0.7. >> >> Is all 3 patches important, or only this is fine: >> build: link dlopen libs with "nodelete" >> smokey/dlopen: fix testcase >> >> Sorry, but can you list down all 3 commits. >> >> >> Thanks, >> Pintu >> >> >> >> Thanks, >> Pintu >> On Wed, Jun 27, 2018 at 6:30 PM Pintu Kumar wrote: >> > >> > Dear Henning, >> > >> > Thanks so much for your reply. >> > I am actually using xenomai-next branch. >> > With last commit as: >> > commit ffb68112e2342a62a1f70916a35a3d68e875b12c >> > Author: Philippe Gerum >> > Date: Mon May 21 12:54:59 2018 +0200 >> > >> > scripts/prepare-kernel.sh: drop left overs from obsolete ports >> > >> > Anyways, I will check with your reference commits. >> > >> > Thanks, >> > Pintu >> > On Wed, Jun 27, 2018 at 6:07 PM Henning Schild >> > wrote: >> > > >> > > Hi Pintu, >> > > >> > > i guess you might be using v3.0.6. There are a couple of commits on top >> > > of that >> > > https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30 >> > > and 2 parents >> > > All three are in v3.0.7, which hopefully solves your problem. >> > > >> > > regards, >> > > Henning >> > > >> > > Am Wed, 27 Jun 2018 16:11:43 +0530 >> > > schrieb Pintu Kumar : >> > > >> > > > Dear Henning, >> > > > >> > > > I saw your commit regarding dlopen here: >> > > > https://xenomai.org/pipermail/xenomai/2018-February/038351.html >> > > > >> > > > We are facing dlopen error with xeno-test on arm (beagle bone) and >> > > > arm64 (hikey) boards. >> > > > Segmentation fault >> > > > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 >> > > > >> > > > Do you have any clue regarding this issue. >> > > > Earlier xeno-test worked for us, but after this commit xeno-test is >> > > > failing. >> > > > >> > > > Currently we dont need dlopen test. >> > > > So, please let us know how to disable dlopen test to pass the >> > > > xeno-test report. >> > > > >> > > > >> > > > Thanks, >> > > > Pintu >> > > > >> > > > >> > > > >> > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar >> > > > wrote: >> > > > > >> > > > > One more thing, >> > > > > On x86 xeno-test works fine even with dlopen. >> > > > > >> > > > > This problem is seen only of arm and arm64 boards. >> > > > > >> > > > > Thanks, >> > > > > Pintu >> > > > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar >> > > > > wrote: >> > > > > > >> > > > > > Ok Greg thanks a lot. >> > > > > > >> > > > > > Yes, I can recompile it, but for now I want to get rid of this >> > > > > > dlopen to pass rest of xeno-test. >> > > > > > Please let me know how to disable it from configure.ac >> > > > > > >> > > > > > Thanks, >> > > > > > Pintu >> > > > > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher >> > > > > > wrote: >> > > > > > > >> > > > > > > Hi, >> > > > > > > I'll take a look at this tonight. I'll confirm if this test >> > > > > > > is crashing on all platforms or just BB. To disable I believe >> > > > > > > you'll have to recompile the tests. >> > > > > > > >> > > > > > > -Greg >> > > > > > > >> > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar >> > > > > > > wrote: >> > > > > > > > Dear Greg, >> > > > > > > > >> > > > > > > > Please let me know how to disable "dlopen" test in >> > > > > > > > xenomai-next. >> > > > > > > > >> > > > > > > > I even tried, without dlopen parameter during ./configure but >> > > > > > > > still I get the same issue. >> > > > > > > > # ./configure --enable-smp >> > > > > > > > >> > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. >> > > > > > > > So, I am planning to disable it right now. >> > > > > > > > Please help! >> > > > > > > > >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > >
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
> With nosmap, that particular issue should no longer occur (at least as
> long as we can ask the kernel for this relaxation), so I suspect the
> other effect you see now is something else.
Just for the information, that issue occurred even on Beagle bone, and
there is no smap on arm.
However, it works on virtual box. how ?
This is the back trace seen on ARM Beagle bone:
{{{
[ 970.717610] Unhandled fault: page domain fault (0x01b) at 0xbe926678
[ 970.724030] pgd = da83
[ 970.726755] [be926678] *pgd=9cda7831, *pte=9a61634f, *ppte=9a61683f
[ 970.733107] Internal error: : 1b [#1] PREEMPT SMP ARM
[ 970.738188] Modules linked in: rt_loopback rtpacket rtudp rtipv4 rtnet
[ 970.744831] CPU: 0 PID: 564 Comm: rtnet-client Not tainted 4.9.51-scel-beagle
bone #6
[ 970.752611] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 970.758733] I-pipe domain: Linux
[ 970.761979] task: dce0d740 task.stack: dce08000
[ 970.766567] PC is at rt_udp_getfrag+0x48/0x118 [rtudp]
[ 970.771796] LR is at rt_ip_build_xmit+0x230/0x2f4 [rtipv4]
[ 970.777313] pc : []lr : []psr: 20060013
[ 970.777313] sp : dce09cf0 ip : bf026bb0 fp : dce09d14
[ 970.788846] r10: dcb35824 r9 : 0400 r8 : c12050a0
[ 970.794099] r7 : dcd9e364 r6 : 000a r5 : dce09db4 r4 :
[ 970.800659] r3 : be926678 r2 : r1 : be926678 r0 :
[ 970.807221] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 970.814392] Control: 10c5387d Table: 9a830019 DAC: 0051
[ 970.820168] Process rtnet-client (pid: 564, stack limit = 0xdce08220)
[ 970.826642] Stack: (0xdce09cf0 to 0xdce0a000)
[ 970.831025] 9ce0: dce09d14 dce09d00 dcc0b
600 dcd9e2c0
[ 970.839249] 9d00: 0040 dcd9e364 dce09d6c dce09d18 bf019688 bf026ba4 c1205
0a0
[ 970.847470] 9d20: dce09d6c dce09d30 bf017d4c bf01c13c 000a dce09db4 bf026
b98 000f
[ 970.855692] 9d40: c120418c dce09e64 0002 dce09d98 dcb35800 dce09
dd4
[ 970.863912] 9d60: dce09ebc dce09d70 bf027098 bf019464 dce09e64 0
000 e015
[ 970.872133] 9d80: 017f c1199b50 c12050a0 c0173fd0 dce09dd4 be926
6cc 0010
[ 970.880354] 9da0: be926678 0001 e015a816 0
a00 017f
[ 970.888576] 9dc0: 017f dcb35800 be926678 0001 be926714 0
002 c0179034
[ 970.896798] 9de0: c12095fc 0002 c120 c010332c c0103340 c015ef90 c0103
32c
[ 970.905020] 9e00: c1209f90 0002 c120 c0112abc c0112ad0 c015ef90 dce09
e4c dce09e28
[ 970.913240] 9e20: dce08000 c01ab530 c015f2d4 0
000
[ 970.921461] 9e40: 0003 0001 c020cdec c027ea78 c1199b50 e0150002 01000
07f
[ 970.929682] 9e60: 017f 0
000
[ 970.937904] 9e80: dcc0b600 00040933 dce09ebc dcb35800 c119a
cf0 40060013
[ 970.946124] 9ea0: 0003 dce09efc c11989b0 dce09ef4 dce09ec0 c027f
6f0 bf026cbc
[ 970.954346] 9ec0: 0052 dce0d740 0003 0051 0
001 e0580008
[ 970.962568] 9ee0: c0285920 c11989b0 dce09f34 dce09ef8 c02859b0 c027f65c e0580
008 be9266cc
[ 970.970789] 9f00: 0010 be926678 0001 dce09
fb0 dce09fb0
[ 970.979010] 9f20: 0052 c12050a0 dce09f6c dce09f38 c029351c c028592c 0
000 dce09f48
[ 970.987231] 9f40: c02d1f68 df9429b0 df9419b0 c12050a0 20060013 c13f7600 c13f7
600 c11989b0
[ 970.995452] 9f60: dce09fac dce09f70 c020d5a0 c029340c c11989b0 c119acf0 c13f7
600 dce09fb0
[ 971.003675] 9f80: c02d8de4 00022080 be926680 000f0042 c0109288 dce08
000 0002
[ 971.011896] 9fa0: dce09fb0 c01091d4 c020d4a8 1054 0003 be926
680
[ 971.020119] 9fc0: 00022080 be926680 000f0042 0003 0002 1
5e0
[ 971.028340] 9fe0: b6f482d0 be926650 b6f2f044 00060030 1054 0
000
[ 971.036617] [] (rt_udp_getfrag [rtudp]) from [] (rt_ip_bu
ild_xmit+0x230/0x2f4 [rtipv4])
[ 971.046445] [] (rt_ip_build_xmit [rtipv4]) from [] (rt_ud
p_sendmsg+0x3e8/0x45c [rtudp])
[ 971.056256] [] (rt_udp_sendmsg [rtudp]) from [] (rtdm_fd_
sendmsg+0xa0/0x248)
[ 971.065095] [] (rtdm_fd_sendmsg) from [] (CoBaLt_sendmsg+
0x90/0x98)
[ 971.073156] [] (CoBaLt_sendmsg) from [] (ipipe_syscall_ho
ok+0x11c/0x400)
[ 971.081647] [] (ipipe_syscall_hook) from [] (__ipipe_noti
fy_syscall+0x104/0x1d4)
[ 971.090841] [] (__ipipe_notify_syscall) from [] (pipeline
_syscall+0x8/0x24)
[ 971.099591] Code: da0a e5953014 e1a02000 e0831184 (e7930184)
[ 971.105740] ---[ end trace 0e2d3ec12e870a84 ]---
}}}
I will try to debug this issue if my time permits.
Thanks,
Pintu
On Wed, Jun 27, 2018 at 4:44 PM Jan Kiszka wrote:
>
> On 2018-06-27 12:56, Pintu Kumar wrote:
> > Dear Jan,
> >
> >> What means "now"? Did it work before? What was the setup then?
> > rtnet loopback test is working (even with older kernel) on
[Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0
Hi all, I need to port some kernel and application code from Xenomai 2.6 to Xenomai 3.0. The existing code creates a semaphore with sem_open() from the *kernel* module init function and posts it with sem_post() from a rtdm interrupt handler (which is also part of the kernel module). The application opens the same semaphore and synchronizes on it using sem_wait(). I can see that the xenomai/posix/posix.h header is gone from the kernel tree. What is the correct way of accessing the semaphore from the kernel code? What headers need to be included? The migration guide focuses more on the application side, but doesn't provide much info for the kernel side. By the way, the old link to the guide at https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ seems to be broken after the gitlab migration. Thanks, Radu Rendec ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
Hi, Sorry, but both the below patches are already applied to my xenomai-next repo: build: link dlopen libs with "nodelete" smokey/dlopen: fix testcase Still I am facing dlopen issue. Is there any other patches I am missing? Thanks, Pintu On Wed, Jun 27, 2018 at 6:47 PM Pintu Kumar wrote: > > Hi, > > One doubt, how do we clone 3.0.7 ? > Is it part of the following branches? > remotes/origin/next > remotes/origin/stable/v3.0.x > > I could not find any branch with the name 3.0.7. > > Is all 3 patches important, or only this is fine: > build: link dlopen libs with "nodelete" > smokey/dlopen: fix testcase > > Sorry, but can you list down all 3 commits. > > > Thanks, > Pintu > > > > Thanks, > Pintu > On Wed, Jun 27, 2018 at 6:30 PM Pintu Kumar wrote: > > > > Dear Henning, > > > > Thanks so much for your reply. > > I am actually using xenomai-next branch. > > With last commit as: > > commit ffb68112e2342a62a1f70916a35a3d68e875b12c > > Author: Philippe Gerum > > Date: Mon May 21 12:54:59 2018 +0200 > > > > scripts/prepare-kernel.sh: drop left overs from obsolete ports > > > > Anyways, I will check with your reference commits. > > > > Thanks, > > Pintu > > On Wed, Jun 27, 2018 at 6:07 PM Henning Schild > > wrote: > > > > > > Hi Pintu, > > > > > > i guess you might be using v3.0.6. There are a couple of commits on top > > > of that > > > https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30 > > > and 2 parents > > > All three are in v3.0.7, which hopefully solves your problem. > > > > > > regards, > > > Henning > > > > > > Am Wed, 27 Jun 2018 16:11:43 +0530 > > > schrieb Pintu Kumar : > > > > > > > Dear Henning, > > > > > > > > I saw your commit regarding dlopen here: > > > > https://xenomai.org/pipermail/xenomai/2018-February/038351.html > > > > > > > > We are facing dlopen error with xeno-test on arm (beagle bone) and > > > > arm64 (hikey) boards. > > > > Segmentation fault > > > > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > > > > > Do you have any clue regarding this issue. > > > > Earlier xeno-test worked for us, but after this commit xeno-test is > > > > failing. > > > > > > > > Currently we dont need dlopen test. > > > > So, please let us know how to disable dlopen test to pass the > > > > xeno-test report. > > > > > > > > > > > > Thanks, > > > > Pintu > > > > > > > > > > > > > > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar > > > > wrote: > > > > > > > > > > One more thing, > > > > > On x86 xeno-test works fine even with dlopen. > > > > > > > > > > This problem is seen only of arm and arm64 boards. > > > > > > > > > > Thanks, > > > > > Pintu > > > > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar > > > > > wrote: > > > > > > > > > > > > Ok Greg thanks a lot. > > > > > > > > > > > > Yes, I can recompile it, but for now I want to get rid of this > > > > > > dlopen to pass rest of xeno-test. > > > > > > Please let me know how to disable it from configure.ac > > > > > > > > > > > > Thanks, > > > > > > Pintu > > > > > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > I'll take a look at this tonight. I'll confirm if this test > > > > > > > is crashing on all platforms or just BB. To disable I believe > > > > > > > you'll have to recompile the tests. > > > > > > > > > > > > > > -Greg > > > > > > > > > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar > > > > > > > wrote: > > > > > > > > Dear Greg, > > > > > > > > > > > > > > > > Please let me know how to disable "dlopen" test in > > > > > > > > xenomai-next. > > > > > > > > > > > > > > > > I even tried, without dlopen parameter during ./configure but > > > > > > > > still I get the same issue. > > > > > > > > # ./configure --enable-smp > > > > > > > > > > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. > > > > > > > > So, I am planning to disable it right now. > > > > > > > > Please help! > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Pintu > > > > > > > > > > > > > > > > On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar > > > > > > > > wrote: > > > > > > > >> > > > > > > > >> Hi, > > > > > > > >> I am using Kernel 4.9.51 for beagle bone black with xenomai > > > > > > > >> patches from xenomai-next repo. > > > > > > > >> > > > > > > > >> I have installed xenomai-3-next using below: > > > > > > > >> # ./scripts/bootstrap > > > > > > > >> # ./configure --with-pic --with-core=cobalt --enable-smp > > > > > > > >> --disable-tls --enable-dlopen-libs > > > > > > > >> # make > > > > > > > >> # make install > > > > > > > >> > > > > > > > >> After that when I run xeno-test I get below error, and the > > > > > > > >> test stopped. > > > > > > > >> > > > > > > > >> # root@bdk:~# /usr/xenomai/bin/xeno-test > > > > > > > >> > > > > > > > >> > > > > > > > >> vdso_access OK > > > > > > > >> xddp skipped (no kernel support) > > > > > > > >> Segmentation fault > > > >
Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
Hi, One doubt, how do we clone 3.0.7 ? Is it part of the following branches? remotes/origin/next remotes/origin/stable/v3.0.x I could not find any branch with the name 3.0.7. Is all 3 patches important, or only this is fine: build: link dlopen libs with "nodelete" smokey/dlopen: fix testcase Sorry, but can you list down all 3 commits. Thanks, Pintu Thanks, Pintu On Wed, Jun 27, 2018 at 6:30 PM Pintu Kumar wrote: > > Dear Henning, > > Thanks so much for your reply. > I am actually using xenomai-next branch. > With last commit as: > commit ffb68112e2342a62a1f70916a35a3d68e875b12c > Author: Philippe Gerum > Date: Mon May 21 12:54:59 2018 +0200 > > scripts/prepare-kernel.sh: drop left overs from obsolete ports > > Anyways, I will check with your reference commits. > > Thanks, > Pintu > On Wed, Jun 27, 2018 at 6:07 PM Henning Schild > wrote: > > > > Hi Pintu, > > > > i guess you might be using v3.0.6. There are a couple of commits on top > > of that > > https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30 > > and 2 parents > > All three are in v3.0.7, which hopefully solves your problem. > > > > regards, > > Henning > > > > Am Wed, 27 Jun 2018 16:11:43 +0530 > > schrieb Pintu Kumar : > > > > > Dear Henning, > > > > > > I saw your commit regarding dlopen here: > > > https://xenomai.org/pipermail/xenomai/2018-February/038351.html > > > > > > We are facing dlopen error with xeno-test on arm (beagle bone) and > > > arm64 (hikey) boards. > > > Segmentation fault > > > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > > > Do you have any clue regarding this issue. > > > Earlier xeno-test worked for us, but after this commit xeno-test is > > > failing. > > > > > > Currently we dont need dlopen test. > > > So, please let us know how to disable dlopen test to pass the > > > xeno-test report. > > > > > > > > > Thanks, > > > Pintu > > > > > > > > > > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar > > > wrote: > > > > > > > > One more thing, > > > > On x86 xeno-test works fine even with dlopen. > > > > > > > > This problem is seen only of arm and arm64 boards. > > > > > > > > Thanks, > > > > Pintu > > > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar > > > > wrote: > > > > > > > > > > Ok Greg thanks a lot. > > > > > > > > > > Yes, I can recompile it, but for now I want to get rid of this > > > > > dlopen to pass rest of xeno-test. > > > > > Please let me know how to disable it from configure.ac > > > > > > > > > > Thanks, > > > > > Pintu > > > > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > I'll take a look at this tonight. I'll confirm if this test > > > > > > is crashing on all platforms or just BB. To disable I believe > > > > > > you'll have to recompile the tests. > > > > > > > > > > > > -Greg > > > > > > > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar > > > > > > wrote: > > > > > > > Dear Greg, > > > > > > > > > > > > > > Please let me know how to disable "dlopen" test in > > > > > > > xenomai-next. > > > > > > > > > > > > > > I even tried, without dlopen parameter during ./configure but > > > > > > > still I get the same issue. > > > > > > > # ./configure --enable-smp > > > > > > > > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. > > > > > > > So, I am planning to disable it right now. > > > > > > > Please help! > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Pintu > > > > > > > > > > > > > > On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar > > > > > > > wrote: > > > > > > >> > > > > > > >> Hi, > > > > > > >> I am using Kernel 4.9.51 for beagle bone black with xenomai > > > > > > >> patches from xenomai-next repo. > > > > > > >> > > > > > > >> I have installed xenomai-3-next using below: > > > > > > >> # ./scripts/bootstrap > > > > > > >> # ./configure --with-pic --with-core=cobalt --enable-smp > > > > > > >> --disable-tls --enable-dlopen-libs > > > > > > >> # make > > > > > > >> # make install > > > > > > >> > > > > > > >> After that when I run xeno-test I get below error, and the > > > > > > >> test stopped. > > > > > > >> > > > > > > >> # root@bdk:~# /usr/xenomai/bin/xeno-test > > > > > > >> > > > > > > >> > > > > > > >> vdso_access OK > > > > > > >> xddp skipped (no kernel support) > > > > > > >> Segmentation fault > > > > > > >> /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > > > >> > > > > > > >> If you have any clue about this error, please let me know. > > > > > > >> > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Pintu > > ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
Dear Henning, Thanks so much for your reply. I am actually using xenomai-next branch. With last commit as: commit ffb68112e2342a62a1f70916a35a3d68e875b12c Author: Philippe Gerum Date: Mon May 21 12:54:59 2018 +0200 scripts/prepare-kernel.sh: drop left overs from obsolete ports Anyways, I will check with your reference commits. Thanks, Pintu On Wed, Jun 27, 2018 at 6:07 PM Henning Schild wrote: > > Hi Pintu, > > i guess you might be using v3.0.6. There are a couple of commits on top > of that > https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30 > and 2 parents > All three are in v3.0.7, which hopefully solves your problem. > > regards, > Henning > > Am Wed, 27 Jun 2018 16:11:43 +0530 > schrieb Pintu Kumar : > > > Dear Henning, > > > > I saw your commit regarding dlopen here: > > https://xenomai.org/pipermail/xenomai/2018-February/038351.html > > > > We are facing dlopen error with xeno-test on arm (beagle bone) and > > arm64 (hikey) boards. > > Segmentation fault > > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > Do you have any clue regarding this issue. > > Earlier xeno-test worked for us, but after this commit xeno-test is > > failing. > > > > Currently we dont need dlopen test. > > So, please let us know how to disable dlopen test to pass the > > xeno-test report. > > > > > > Thanks, > > Pintu > > > > > > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar > > wrote: > > > > > > One more thing, > > > On x86 xeno-test works fine even with dlopen. > > > > > > This problem is seen only of arm and arm64 boards. > > > > > > Thanks, > > > Pintu > > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar > > > wrote: > > > > > > > > Ok Greg thanks a lot. > > > > > > > > Yes, I can recompile it, but for now I want to get rid of this > > > > dlopen to pass rest of xeno-test. > > > > Please let me know how to disable it from configure.ac > > > > > > > > Thanks, > > > > Pintu > > > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher > > > > wrote: > > > > > > > > > > Hi, > > > > > I'll take a look at this tonight. I'll confirm if this test > > > > > is crashing on all platforms or just BB. To disable I believe > > > > > you'll have to recompile the tests. > > > > > > > > > > -Greg > > > > > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar > > > > > wrote: > > > > > > Dear Greg, > > > > > > > > > > > > Please let me know how to disable "dlopen" test in > > > > > > xenomai-next. > > > > > > > > > > > > I even tried, without dlopen parameter during ./configure but > > > > > > still I get the same issue. > > > > > > # ./configure --enable-smp > > > > > > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. > > > > > > So, I am planning to disable it right now. > > > > > > Please help! > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Pintu > > > > > > > > > > > > On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar > > > > > > wrote: > > > > > >> > > > > > >> Hi, > > > > > >> I am using Kernel 4.9.51 for beagle bone black with xenomai > > > > > >> patches from xenomai-next repo. > > > > > >> > > > > > >> I have installed xenomai-3-next using below: > > > > > >> # ./scripts/bootstrap > > > > > >> # ./configure --with-pic --with-core=cobalt --enable-smp > > > > > >> --disable-tls --enable-dlopen-libs > > > > > >> # make > > > > > >> # make install > > > > > >> > > > > > >> After that when I run xeno-test I get below error, and the > > > > > >> test stopped. > > > > > >> > > > > > >> # root@bdk:~# /usr/xenomai/bin/xeno-test > > > > > >> > > > > > >> > > > > > >> vdso_access OK > > > > > >> xddp skipped (no kernel support) > > > > > >> Segmentation fault > > > > > >> /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > > >> > > > > > >> If you have any clue about this error, please let me know. > > > > > >> > > > > > >> > > > > > >> Thanks, > > > > > >> Pintu > ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
Hi Pintu, i guess you might be using v3.0.6. There are a couple of commits on top of that https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30 and 2 parents All three are in v3.0.7, which hopefully solves your problem. regards, Henning Am Wed, 27 Jun 2018 16:11:43 +0530 schrieb Pintu Kumar : > Dear Henning, > > I saw your commit regarding dlopen here: > https://xenomai.org/pipermail/xenomai/2018-February/038351.html > > We are facing dlopen error with xeno-test on arm (beagle bone) and > arm64 (hikey) boards. > Segmentation fault > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > Do you have any clue regarding this issue. > Earlier xeno-test worked for us, but after this commit xeno-test is > failing. > > Currently we dont need dlopen test. > So, please let us know how to disable dlopen test to pass the > xeno-test report. > > > Thanks, > Pintu > > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar > wrote: > > > > One more thing, > > On x86 xeno-test works fine even with dlopen. > > > > This problem is seen only of arm and arm64 boards. > > > > Thanks, > > Pintu > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar > > wrote: > > > > > > Ok Greg thanks a lot. > > > > > > Yes, I can recompile it, but for now I want to get rid of this > > > dlopen to pass rest of xeno-test. > > > Please let me know how to disable it from configure.ac > > > > > > Thanks, > > > Pintu > > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher > > > wrote: > > > > > > > > Hi, > > > > I'll take a look at this tonight. I'll confirm if this test > > > > is crashing on all platforms or just BB. To disable I believe > > > > you'll have to recompile the tests. > > > > > > > > -Greg > > > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar > > > > wrote: > > > > > Dear Greg, > > > > > > > > > > Please let me know how to disable "dlopen" test in > > > > > xenomai-next. > > > > > > > > > > I even tried, without dlopen parameter during ./configure but > > > > > still I get the same issue. > > > > > # ./configure --enable-smp > > > > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. > > > > > So, I am planning to disable it right now. > > > > > Please help! > > > > > > > > > > > > > > > Thanks, > > > > > Pintu > > > > > > > > > > On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar > > > > > wrote: > > > > >> > > > > >> Hi, > > > > >> I am using Kernel 4.9.51 for beagle bone black with xenomai > > > > >> patches from xenomai-next repo. > > > > >> > > > > >> I have installed xenomai-3-next using below: > > > > >> # ./scripts/bootstrap > > > > >> # ./configure --with-pic --with-core=cobalt --enable-smp > > > > >> --disable-tls --enable-dlopen-libs > > > > >> # make > > > > >> # make install > > > > >> > > > > >> After that when I run xeno-test I get below error, and the > > > > >> test stopped. > > > > >> > > > > >> # root@bdk:~# /usr/xenomai/bin/xeno-test > > > > >> > > > > >> > > > > >> vdso_access OK > > > > >> xddp skipped (no kernel support) > > > > >> Segmentation fault > > > > >> /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > > >> > > > > >> If you have any clue about this error, please let me know. > > > > >> > > > > >> > > > > >> Thanks, > > > > >> Pintu ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
On 2018-06-27 12:56, Pintu Kumar wrote: > Dear Jan, > >> What means "now"? Did it work before? What was the setup then? > rtnet loopback test is working (even with older kernel) on my Virtual > Box with Ubuntu 32-bit. > > But it never worked for me on x86_64 machine. > So, at first I wonder what is the minimum criteria to make rtnet work > on any system. > I am sure it would have definitely worked in the past. No? It surely worked, but it wasn't looked after consistently in the (even not so) recent past since then. > >> Either you drill deeper, systematically, and report your >> findings for discussions and suggestions on the list > Yes sure, I am ready to do that. > Once I know the little bit of history and current problems with rtnet, > I can definitely start contributing. > At first I assumed that there might be some fix already available. > So, instead of reinventing the wheel, I thought to first check out. The main recent problem was (and still is) related to SMAP (supervisor mode access prevention) which started to bite RTnet due to its sloppy way of taken data from user space or pushing it back there (not using proper copy-to/from services). The problem in the UDP code you ran into is related to the code still doing direct access (checksum generation over userspace data, rather than over the kernel copy). With nosmap, that particular issue should no longer occur (at least as long as we can ask the kernel for this relaxation), so I suspect the other effect you see now is something else. Jan > > I am really sorry for troubling you! > I will try to look into this issue and see if I can find something. > > Thank you! > Pintu > > On Wed, Jun 27, 2018 at 3:50 PM Jan Kiszka wrote: >> >> On 2018-06-26 13:08, Pintu Kumar wrote: >>> Dear Jan, >>> >>> Till now I haven't had any success for running my rtnet demo test >>> either or x86 or arm. >>> I even upgraded to xenomai-next (both kernel and user space) but still no >>> luck. >>> >>> Now even the "loopback" test is not working on xenomai-next. >> >> What means "now"? Did it work before? What was the setup then? >> >>> >>> Can you confirm, if any of the below rtnet test works for you with >>> Kernel 4.9 and xenomai-next. >>> - xenomai-3-next/testsuite/smokey/net_udp >>> - url = https://git.code.sf.net/p/rtnet/code => examples/generic/ >>> - Or a simple UDP client/server program, compiled with xenomai posix skin >>> >>> I already tried with "nosmap" but there are no response coming (I am >>> getting no prints on console, but client is terminated). >>> If there is any work around to make rtnet works, please let me know. >>> >> >> I'm afraid there is currently a lack of bandwidth here to dive into the >> details. Either you drill deeper, systematically, and report your >> findings for discussions and suggestions on the list, or you need to be >> patient until someone finds the time to reproduce and resolve the issue(s). >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >> Corporate Competence Center Embedded Linux -- 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
[Xenomai] [PATCH] can: Fix compiler warning about missing braces
The NULL-test is currently performed also in case we assign a
pre-checked value from the master to base_addr. This is harmless, but
the compiler correctly complains about the misaligned code block - or
the missing braces.
Signed-off-by: Jan Kiszka
---
kernel/drivers/can/sja1000/rtcan_adv_pci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/drivers/can/sja1000/rtcan_adv_pci.c
b/kernel/drivers/can/sja1000/rtcan_adv_pci.c
index dc8ea2ee4d..32cf71ee1f 100644
--- a/kernel/drivers/can/sja1000/rtcan_adv_pci.c
+++ b/kernel/drivers/can/sja1000/rtcan_adv_pci.c
@@ -158,14 +158,15 @@ static int rtcan_adv_pci_add_chan(struct pci_dev *pdev,
(struct rtcan_adv_pci *)(*master_dev)->board_priv;
master_board->slave_dev = dev;
- if (offset)
+ if (offset) {
base_addr = master_board->base_addr+offset;
- else
+ } else {
base_addr = pci_iomap(pdev, bar, ADV_PCI_BASE_SIZE);
if (!base_addr) {
ret = -EIO;
goto failure;
}
+ }
} else {
base_addr = pci_iomap(pdev, bar, ADV_PCI_BASE_SIZE) + offset;
if (!base_addr) {
--
2.16.4
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
Dear Jan, > What means "now"? Did it work before? What was the setup then? rtnet loopback test is working (even with older kernel) on my Virtual Box with Ubuntu 32-bit. But it never worked for me on x86_64 machine. So, at first I wonder what is the minimum criteria to make rtnet work on any system. I am sure it would have definitely worked in the past. No? > Either you drill deeper, systematically, and report your > findings for discussions and suggestions on the list Yes sure, I am ready to do that. Once I know the little bit of history and current problems with rtnet, I can definitely start contributing. At first I assumed that there might be some fix already available. So, instead of reinventing the wheel, I thought to first check out. I am really sorry for troubling you! I will try to look into this issue and see if I can find something. Thank you! Pintu On Wed, Jun 27, 2018 at 3:50 PM Jan Kiszka wrote: > > On 2018-06-26 13:08, Pintu Kumar wrote: > > Dear Jan, > > > > Till now I haven't had any success for running my rtnet demo test > > either or x86 or arm. > > I even upgraded to xenomai-next (both kernel and user space) but still no > > luck. > > > > Now even the "loopback" test is not working on xenomai-next. > > What means "now"? Did it work before? What was the setup then? > > > > > Can you confirm, if any of the below rtnet test works for you with > > Kernel 4.9 and xenomai-next. > > - xenomai-3-next/testsuite/smokey/net_udp > > - url = https://git.code.sf.net/p/rtnet/code => examples/generic/ > > - Or a simple UDP client/server program, compiled with xenomai posix skin > > > > I already tried with "nosmap" but there are no response coming (I am > > getting no prints on console, but client is terminated). > > If there is any work around to make rtnet works, please let me know. > > > > I'm afraid there is currently a lack of bandwidth here to dive into the > details. Either you drill deeper, systematically, and report your > findings for discussions and suggestions on the list, or you need to be > patient until someone finds the time to reproduce and resolve the issue(s). > > 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] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed
Dear Henning, I saw your commit regarding dlopen here: https://xenomai.org/pipermail/xenomai/2018-February/038351.html We are facing dlopen error with xeno-test on arm (beagle bone) and arm64 (hikey) boards. Segmentation fault /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 Do you have any clue regarding this issue. Earlier xeno-test worked for us, but after this commit xeno-test is failing. Currently we dont need dlopen test. So, please let us know how to disable dlopen test to pass the xeno-test report. Thanks, Pintu On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar wrote: > > One more thing, > On x86 xeno-test works fine even with dlopen. > > This problem is seen only of arm and arm64 boards. > > Thanks, > Pintu > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar wrote: > > > > Ok Greg thanks a lot. > > > > Yes, I can recompile it, but for now I want to get rid of this dlopen > > to pass rest of xeno-test. > > Please let me know how to disable it from configure.ac > > > > Thanks, > > Pintu > > On Tue, Jun 26, 2018 at 8:57 PM Greg Gallagher > > wrote: > > > > > > Hi, > > > I'll take a look at this tonight. I'll confirm if this test is > > > crashing on all platforms or just BB. To disable I believe you'll > > > have to recompile the tests. > > > > > > -Greg > > > > > > On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar > > > wrote: > > > > Dear Greg, > > > > > > > > Please let me know how to disable "dlopen" test in xenomai-next. > > > > > > > > I even tried, without dlopen parameter during ./configure but still I > > > > get the same issue. > > > > # ./configure --enable-smp > > > > > > > > We did not face this issue earlier on xenomai-3 stable branch. > > > > So, I am planning to disable it right now. > > > > Please help! > > > > > > > > > > > > Thanks, > > > > Pintu > > > > > > > > On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar > > > > wrote: > > > >> > > > >> Hi, > > > >> I am using Kernel 4.9.51 for beagle bone black with xenomai patches > > > >> from xenomai-next repo. > > > >> > > > >> I have installed xenomai-3-next using below: > > > >> # ./scripts/bootstrap > > > >> # ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls > > > >> --enable-dlopen-libs > > > >> # make > > > >> # make install > > > >> > > > >> After that when I run xeno-test I get below error, and the test > > > >> stopped. > > > >> > > > >> # root@bdk:~# /usr/xenomai/bin/xeno-test > > > >> > > > >> > > > >> vdso_access OK > > > >> xddp skipped (no kernel support) > > > >> Segmentation fault > > > >> /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1 > > > >> > > > >> If you have any clue about this error, please let me know. > > > >> > > > >> > > > >> Thanks, > > > >> Pintu ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Xenomai Meetup at Embedded Linux Conference Europe
Hi all, ELC-E is coming, October 22-24 in Edinburgh, and I've received some indications that there is interest in having another meetup of the community. The question is now how broad that interest is and what form we should head for. Options: - BoF at ELC-E (1h, evening session): - brief update from the project - open discussion about user requirements, to-dos, contributions, etc. - mini-summit at ELC-E (3-4 hours, but I'm concerned we won't get that slot) - project update - user presentations - BoF session(s) - separate meetup in a venue nearby (half day as well) - [same as mini-summit] Please drop a note if you are interested and in what form/topics, either here on the list or privately. I need to decide by July 1 if and how we should apply for a slot at ELC-E. Cheers, 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
[Xenomai] rtcan loopback behaviour when physical device is in error
Hi, With xenomai 3 (but i think the behaviour was the same with xenomai 2), with loopback enabled, when there is no physical device on the bus, the following happens : * the messages fill the internal socket buffers. this result in any blocking send call actually blocking the caller * when this happens, this also block the loopback interface, since can messages are only loopbacked if succesfully sent to the physical interface. We would like to change the behaviour in the following way : * if the physical interface is in error, and there is a single client, no change (ie, continue to block) * if the physical interface is in error, but there are multiple clients (ie, the loopback will be trigged), then : * discard the message from the physical interface * loopback the messages to the connected clients We believe this is a more logical behaviour if each program working with the rtcan is seen as a separate physical device -> the error of one device should not compromise the communication between others, while still remain the behaviour that if no one listens, then the message cannot be sent. This is a big change, and likely to break any code that rely on the previous behaviour. So, questions : * has such a change any chance to reach mainline xenomai ? (we're gonna do and provide the necessary patches) * if so, should this behaviour be made optional ? The loopback property could be changed from a single yes/no to a tri-valued easily in that regard. Thanks, Julien ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
