Re: Mode Switch

perfect it works! Thanks! Il giorno lun 15 feb 2021 alle ore 14:57 Julien Blanc via Xenomai < xenomai@xenomai.org> ha scritto: > Le lundi 15 février 2021 à 14:52 +0100, Leandro Bucci via Xenomai a > écrit : > > What I want is to have a function that generates me mode switches > >

Re: Mode Switch

Le lundi 15 février 2021 à 14:52 +0100, Leandro Bucci via Xenomai a écrit : > What I want is to have a function that generates me mode switches __STD(nanosleep)(timeout, NULL) with a zero timeout should do it. and you can use any switch-primary call to go back to primary mode. Regards, Julien

Re: Mode Switch

What I want is to have a function that generates me mode switches Il giorno lun 15 feb 2021 alle ore 14:46 Per Oberg ha scritto: > > - Den 15 feb 2021, på kl 14:16, Leandro Bucci guestleandr...@gmail.com > skrev: > > > Yes I want a mode switch happened, thank for your answ

Re: Mode Switch

- Den 15 feb 2021, på kl 14:16, Leandro Bucci guestleandr...@gmail.com skrev: > Yes I want a mode switch happened, thank for your answer > Il lun 15 feb 2021, 14:15 Per Oberg < [ mailto:p...@wolfram.com | > p...@wolfram.com ] > ha scritto: >> - Den 15 feb 2021,

Re: Mode Switch

Yes I want a mode switch happened, thank for your answer Il lun 15 feb 2021, 14:15 Per Oberg ha scritto: > - Den 15 feb 2021, på kl 14:00, xenomai xenomai@xenomai.org skrev: > > > hi, I can't understand why if I use the memcpy function on Xenomai I > don't > >

Mode Switch

hi, I can't understand why if I use the memcpy function on Xenomai I don't have any mode switch. Is there a function that copies two arrays and generates a mode switch?

Re: mmap64 causes secondary mode switch

28 in PeriodicTask::task_caller (_task=0x46aee0) at > /data/sam/mocha-death/tonkatime/src/common/periodic_task.cpp:27 > #9 0x007fbf5c8e68 in ?? () from /usr/xenomai/lib/libcobalt.so.2 > #10 0x007fbf57b6cc in start_thread () from /lib/libpthread.so.0 > #11 0x007fbf26cf7

mmap64 causes secondary mode switch

/xenomai/lib/libcobalt.so.2 #10 0x007fbf57b6cc in start_thread () from /lib/libpthread.so.0 #11 0x007fbf26cf7c in ?? () from /lib/libc.so.6 This seems like the mode switch happens on the mmap64 call. From everything I can tell, mmap64 should be a wrapped and supported system call, thus

Re: Mode Switch

n happens in secondary mode, so there's gotta be at least *one* mode switch on the way to becoming a cobalt thread running in primary mode, perhaps the second one has to do with launching the background printf() helper thread? On 1/3/2021 4:08 PM, Leandro Bucci wrote: But in the task I

Re: Mode Switch

appens in secondary mode, so there's gotta be at least > *one* mode switch on the way to becoming a cobalt thread running in primary > mode, perhaps the second one has to do with launching the background > printf() helper thread? > > > > On 1/3/2021 4:08 PM, Leandro Bucci wrote: >

Re: Mode Switch

Might need some help from Philippe on this one but my thinking says that thread creation happens in secondary mode, so there's gotta be at least *one* mode switch on the way to becoming a cobalt thread running in primary mode, perhaps the second one has to do with launching the background

Re: Mode Switch

gt; > > msw incremented by 1, csw would increment by 2. > > > On 1/3/2021 2:29 PM, Leandro Bucci via Xenomai wrote: > > Hi, I have a strange behavior regarding the "mode switch". > In the attached code, the task should never switch to the Linux domain, but > i

Re: Mode Switch

Each time I would do something like this: printf(...) ; fflush(stdout) ; rt_task_sleep(1e9/5) ; rt_task_inquire(...) ; msw incremented by 1, csw would increment by 2. On 1/3/2021 2:29 PM, Leandro Bucci via Xenomai wrote: Hi, I have a strange behavior regarding the "mode s

Mode Switch

Hi, I have a strange behavior regarding the "mode switch". In the attached code, the task should never switch to the Linux domain, but instead I have a value of MSW = 2. How is it possible? Even if I do a printf in the task I always get MSW = 2. I can't understand where the problem is.

Re: Waking up a linux thread from a xenomai thread, without mode switch

On 12/14/18 2:16 PM, Julien Blanc wrote: > Le vendredi 14 décembre 2018 à 12:07 +0100, Philippe Gerum a écrit : >> >> You could use non-rt Xenomai threads on the linux side with policies >> SCHED_FIFO+prio=0 or SCHED_WEAK, allowing the thread to issue >> blocking >> Xenomai syscalls (such as

Re: Waking up a linux thread from a xenomai thread, without mode switch

Le vendredi 14 décembre 2018 à 12:07 +0100, Philippe Gerum a écrit : > > You could use non-rt Xenomai threads on the linux side with policies > SCHED_FIFO+prio=0 or SCHED_WEAK, allowing the thread to issue > blocking > Xenomai syscalls (such as waiting on a Cobalt sema4). > > But, since this

Re: Waking up a linux thread from a xenomai thread, without mode switch

On 12/14/18 11:48 AM, Julien Blanc via Xenomai wrote: > Hi, > > We’re currently using semaphores and a shared buffer to allow > communication between a xenomai cobalt thread and a linux regular > thread (the xddp interface has been tested and does not perform well > for our use case, which is

Re: Waking up a linux thread from a xenomai thread, without mode switch

ur use case, which is exchanging a lot a very small messages). > > While this works fine most of the time, we’ve noticed that this incurs > a mode switch when the xenomai rt-thread calls real_sem_post, and, > under heavy load, it can results in that specific thread being > suspended for too

Waking up a linux thread from a xenomai thread, without mode switch

of the time, we’ve noticed that this incurs a mode switch when the xenomai rt-thread calls real_sem_post, and, under heavy load, it can results in that specific thread being suspended for too long. I couldn’t find in the documentation how to do this properly : * waiting on a xenomai semaphore from

Re: [Xenomai] Secondary mode switch monitoring

Have you read over the link below? https://xenomai.org/2014/06/finding-spurious-relaxes/ There's been some discussion on the list about this subject recently take a look at the archive. -Greg On Fri, Apr 20, 2018 at 12:28 PM, Pintu Kumar wrote: > Hi, > > Is there a way

[Xenomai] Secondary mode switch monitoring

Hi, Is there a way to monitor secondary mode switching happening for Xenomai dual kernel? Like for example: For my particular application, I wanted to know how many times the primary mode to secondary mode switching actually happened, for some specific scenario. If there is already some way to

Re: [Xenomai] Writing to UDD driver through mapped memory cause secondary mode switch

Hello Greg, I didn't succeed to solve this issue. The switch to secondary mode only happen on the first write to the memory mapped area. As far as I understood, the secondary mode switch is caused by a page fault. I workaround it by doing a dummy write just after the mmap() call, which anyway

Re: [Xenomai] Writing to UDD driver through mapped memory cause secondary mode switch

ide, Xenomai > switches to secondary mode. > > I activated the SIGDEBUG and attached an handler to point the origin and the > reason of this secondary mode switch. > The result of sigdebug_reason(siginfo) is SIGDEBUG_MIGRATE_FAULT. > > I'm using mmap with the following attrib

Re: [Xenomai] mode switch caused by __lll_lock_wait_private()

>> >> We're testing our application now by running it continuously over >> weeks. I randomly reports the following mode switches in the log: >> >> > 0x2b03a420 0x93980 > >> >> With the process memory map from /proc//maps: >> >> ... >> 2af68000-2b084000 r-xp 00:0d 22235 /lib/libc-2.14.1.so

[Xenomai] Writing to UDD driver through mapped memory cause secondary mode switch

an handler to point the origin and the reason of this secondary mode switch. The result of sigdebug_reason(siginfo) is SIGDEBUG_MIGRATE_FAULT. I'm using mmap with the following attributes: mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fpgaMemfd, 0); The file descriptor is opened with O_RDWR flag

Re: [Xenomai] mode switch caused by __lll_lock_wait_private()

Am Fri, 8 Dec 2017 13:14:16 + schrieb Andreas Glatz : > Hi > > We're testing our application now by running it continuously over > weeks. I randomly reports the following mode switches in the log: > > 0x2b03a420 0x93980 > > > With the process memory map from

[Xenomai] mode switch caused by __lll_lock_wait_private()

Hi We're testing our application now by running it continuously over weeks. I randomly reports the following mode switches in the log: With the process memory map from /proc//maps: ... 2af68000-2b084000 r-xp 00:0d 22235 /lib/libc-2.14.1.so ... and output from -objdump -d

Re: [Xenomai] rtdm_safe_copy_from_user() causing mode switch

are(spim->clk); clk_disable_unprepare(spim->clk_ipg); clk_disable_unprepare(spim->clk_per); fail: spi_master_put(kmaster); return ret; } static int spi_imx_remove(struct platform_device *pdev) { struct rtdm_spi_master *master = platform_get_drvdata(pdev); struct spi_master_

Re: [Xenomai] rtdm_safe_copy_from_user() causing mode switch

On 10/07/2017 03:56 AM, Jackson Jones wrote: > I noticed that when I call rtdm_safe_copy_from_user() it causes a mode > switch. I am looking to pass a uint32_t (u32 in kernel space) from > user-space to a rtdm driver. > > Is there a way of doing this that avoids a mode swi

[Xenomai] rtdm_safe_copy_from_user() causing mode switch

I noticed that when I call rtdm_safe_copy_from_user() it causes a mode switch. I am looking to pass a uint32_t (u32 in kernel space) from user-space to a rtdm driver. Is there a way of doing this that avoids a mode switch. I am doing this in an rtdm spi driver for the imx6. It is used to change

[Xenomai-git] Philippe Gerum : lib/copperplate: prevent unwanted mode switch during thread prologue

wanted mode switch during thread prologue copperplate_renice_local_thread() causes a switch to secondary mode for an emerging thread context, we want it to happen before such thread handshakes with its parent, so that the later is released only after the child is waiting in primary mode on the

[Xenomai-git] Philippe Gerum : lib/copperplate: prevent unwanted mode switch during thread prologue

revent unwanted mode switch during thread prologue copperplate_renice_local_thread() causes a switch to secondary mode for an emerging thread context, we want it to happen before such thread handshakes with its parent, so that the later is released only after the child is waiting in primar

[Xenomai-git] Philippe Gerum : drivers/gpio: sanitize DEBUG mode switch

DEBUG mode switch --- kernel/drivers/gpio/Makefile|2 ++ kernel/drivers/gpio/gpio-core.c |3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile index e237279..c9e976f 100644 --- a/kernel/drivers/gpio/Makefile

[Xenomai-git] Philippe Gerum : drivers/spi: sanitize DEBUG mode switch

Module: xenomai-3 Branch: master Commit: 121c9feb407e259e27995f70ba63b8a64ac071b6 URL: http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=121c9feb407e259e27995f70ba63b8a64ac071b6 Author: Philippe Gerum <r...@xenomai.org> Date: Tue Jun 28 10:49:26 2016 +0200 drivers/spi: sanitize DEBU

[Xenomai-git] Philippe Gerum : drivers/spi: sanitize DEBUG mode switch

nitize DEBUG mode switch --- kernel/drivers/spi/Makefile |2 ++ kernel/drivers/spi/spi-bcm2835.c |3 --- kernel/drivers/spi/spi-device.c |3 --- kernel/drivers/spi/spi-master.c |3 --- 4 files changed, 2 insertions(+), 9 deletions(-) diff --git a/kernel/drivers/spi/Makefile b/

[Xenomai-git] Philippe Gerum : drivers/gpio: sanitize DEBUG mode switch

nitize DEBUG mode switch --- kernel/drivers/gpio/Makefile|2 ++ kernel/drivers/gpio/gpio-core.c |3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile index e237279..c9e976f 100644 --- a/kernel/drivers/gpio/Ma

[Xenomai-git] Philippe Gerum : drivers/gpio: sanitize DEBUG mode switch

nitize DEBUG mode switch --- kernel/drivers/gpio/Makefile|2 ++ kernel/drivers/gpio/gpio-core.c |3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile index e237279..c9e976f 100644 --- a/kernel/drivers/gpio/Ma

[Xenomai-git] Philippe Gerum : drivers/spi: sanitize DEBUG mode switch

DEBUG mode switch --- kernel/drivers/spi/Makefile |2 ++ kernel/drivers/spi/spi-bcm2835.c |3 --- kernel/drivers/spi/spi-device.c |3 --- kernel/drivers/spi/spi-master.c |3 --- 4 files changed, 2 insertions(+), 9 deletions(-) diff --git a/kernel/drivers/spi/Makefile b/

Re: [Xenomai] Writing into files without mode switch

>You could have a Linux process writing in your file data coming from >your RT process through IPC RT communication. I have a question on this: what IPC method would you recommend? If I understand correctly, mode switches carry an overhead. If this is true, I guess is it reasonable to try to

Re: [Xenomai] Writing into files without mode switch

on an ARM 32-bit(BeagleBone Black). Right now we need a way to write into files without getting a mode switch. I tried to use the rtdk.h header, but it won't work. rt_printf works perfectly fine, but I am not able to write something in a file. The code is compiled with gcc and the xenomai flags

Re: [Xenomai] Writing into files without mode switch

On Fri, Nov 04, 2016 at 12:55:01AM +0100, Florian G. wrote: > I'm using Xenomai 2.6.5 on a 3.8.13 kernel on an ARM 32-bit(BeagleBone > Black). > Right now we need a way to write into files without getting a mode switch. > I tried to use the rtdk.h header, but it won't work. >

[Xenomai] Writing into files without mode switch

Hi, I'm using Xenomai 2.6.5 on a 3.8.13 kernel on an ARM 32-bit(BeagleBone Black). Right now we need a way to write into files without getting a mode switch. I tried to use the rtdk.h header, but it won't work. rt_printf works perfectly fine, but I am not able to write something in a file

[Xenomai-git] Philippe Gerum : drivers/spi: sanitize DEBUG mode switch

DEBUG mode switch --- kernel/drivers/spi/Makefile |2 ++ kernel/drivers/spi/spi-bcm2835.c |3 --- kernel/drivers/spi/spi-device.c |3 --- kernel/drivers/spi/spi-master.c |3 --- 4 files changed, 2 insertions(+), 9 deletions(-) diff --git a/kernel/drivers/spi/Makefile b/

[Xenomai-git] Philippe Gerum : drivers/gpio: sanitize DEBUG mode switch

nitize DEBUG mode switch --- kernel/drivers/gpio/Makefile|2 ++ kernel/drivers/gpio/gpio-core.c |3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile index e237279..c9e976f 100644 --- a/kernel/drivers/gpio/Ma

[Xenomai-git] Philippe Gerum : drivers/testing: add test helpers for mode switch handover

d test helpers for mode switch handover --- include/rtdm/uapi/testing.h |9 + kernel/drivers/testing/rtdmtest.c | 33 +++-- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/rtdm/uapi/testing.h b/include/rtdm/uapi/testing.h

[Xenomai-git] Philippe Gerum : drivers/testing: add test helpers for mode switch handover

d test helpers for mode switch handover --- include/rtdm/uapi/testing.h |9 + kernel/drivers/testing/rtdmtest.c | 33 +++-- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/rtdm/uapi/testing.h b/include/rtdm/uapi/testing.h

[Xenomai-git] Philippe Gerum : drivers/testing: add test helpers for mode switch handover

elpers for mode switch handover --- include/rtdm/uapi/testing.h |9 + kernel/drivers/testing/rtdmtest.c | 33 +++-- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/rtdm/uapi/testing.h b/include/rtdm/uapi/testing.h index 5

[Xenomai-git] Philippe Gerum : drivers/testing: add test helpers for mode switch handover

d test helpers for mode switch handover --- include/rtdm/uapi/testing.h |9 + kernel/drivers/testing/rtdmtest.c | 33 +++-- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/rtdm/uapi/testing.h b/include/rtdm/uapi/testing.h

[Xenomai-git] Philippe Gerum : smokey/rtdm: test mode switch handover

Module: xenomai-3 Branch: wip/handover Commit: 92644e7468953c3a034657ae6ec35ac2732cfd43 URL: http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=92644e7468953c3a034657ae6ec35ac2732cfd43 Author: Philippe Gerum <r...@xenomai.org> Date: Fri Jul 8 10:03:19 2016 +0200 smokey/rtdm: tes

[Xenomai-git] Philippe Gerum : drivers/gpio: sanitize DEBUG mode switch

nitize DEBUG mode switch --- kernel/drivers/gpio/Makefile|2 ++ kernel/drivers/gpio/gpio-core.c |3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile index e237279..c9e976f 100644 --- a/kernel/drivers/gpio/Ma

[Xenomai-git] Gilles Chanteperdrix : latency: only ignore SIGDEBUG if reason is mode switch

latency: only ignore SIGDEBUG if reason is mode switch and various cleanups --- testsuite/latency/latency.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/testsuite/latency/latency.c b/testsuite/latency/latency.c index 2cb874e..02669a1 100644

Re: [Xenomai] memory mapped IO and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

On 09/24/2013 10:06 AM, stefano.franz...@marposs.com wrote: I tried the function rt_timer_tsc but it does not generate the swap to secondary mode. It seems that the first write access generates the fault instead the read accesses do not generate it. I attach a simple example. Then I am

Re: [Xenomai] memory mapped IO and secondary mode switch

: [Xenomai] memory mapped IO and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

, xenomai@xenomai.org Subject Re: [Xenomai] memory mapped IO and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

Re: [Xenomai] memory mapped IO and secondary mode switch

[Xenomai] memory mapped IO and secondary mode switch

a memory mapped IO. Using an oscilloscope I have seen a very little gitter but enabling the trace on secondary mode switch I have seen that the access to memory mapped IO, triggers the event of secondary mode switch. I have used open /dev(mem and mmap outside the rt task and I have obtained

Re: [Xenomai] memory mapped IO and secondary mode switch

), with high priority, that periodically access a memory mapped IO. Using an oscilloscope I have seen a very little gitter but enabling the trace on secondary mode switch I have seen that the access to memory mapped IO, triggers the event of secondary mode switch. I have used open /dev(mem and mmap

Re: [Xenomai] memory mapped IO and secondary mode switch

stefano.franz...@marposs.com wrote: These is the initialization functions StartAddress = 0x6000 Size = 4096 ... int memD = open(/dev/mem, O_RDWR | O_SYNC)) .. vouid *pMemIO = mmap(0, Size, PROT_READ | PROT_WRITE, MAP_SHARED, memD, StartAddress); ... Then all access are made to