Re: rt_task_self() return value

On Tue, 2019-11-19 at 17:05 +0100, Jan Kiszka wrote: > On 19.11.19 17:01, Mauro Salvini wrote: > > On Tue, 2019-11-19 at 16:41 +0100, Jan Kiszka wrote: > > > On 19.11.19 16:29, Mauro Salvini via Xenomai wrote: > > > > Hi all, > > > > > > > >

Re: rt_task_self() return value

On Tue, 2019-11-19 at 16:41 +0100, Jan Kiszka wrote: > On 19.11.19 16:29, Mauro Salvini via Xenomai wrote: > > Hi all, > > > > I'm using Xenomai 3.0.9 in cobalt mode and I'm facing an issue on > > rt_task_self() returned value. > > > > Please see this simpl

rt_task_self() return value

Hi all, I'm using Xenomai 3.0.9 in cobalt mode and I'm facing an issue on rt_task_self() returned value. Please see this simple code: #include #include #include #include RT_TASK gNewTask; static void Task(void *lpArgument) { rt_printf("Task created.\n"); gNewTask =

Re: FPU warn on ipipe 4.9.146-8 i386

On Mon, 2019-01-14 at 10:39 +0100, Henning Schild wrote: > Am Fri, 11 Jan 2019 14:47:13 +0100 > schrieb Mauro Salvini : > > > On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote: > > > Am Fri, 11 Jan 2019 09:57:50 +0100 > > > schrieb Mauro Salvini via

Re: FPU warn on ipipe 4.9.146-8 i386

On Fri, 2019-01-11 at 17:53 +0800, limingyu via Xenomai wrote: > Hi, Mauro > > Maybe you could refer to this disscusion below, and try the latesst  > stable xenomai code branch > > v3.0.x/stable.  > https://xenomai.org/pipermail/xenomai/2018-December/040086.html > > And the lasted xenomai code

Re: FPU warn on ipipe 4.9.146-8 i386

On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote: > Am Fri, 11 Jan 2019 09:57:50 +0100 > schrieb Mauro Salvini via Xenomai : > > > Hi all, > > > > I'm testing same hardware of [1], with kernel 4.9.146 from ipipe- > > 4.9.y > > with [2] applied, co

Re: [PATCHv2] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

On Tue, 2019-01-08 at 18:51 +0100, Henning Schild wrote: > Am Tue, 8 Jan 2019 15:17:11 +0100 > schrieb Mauro Salvini : > > > On Mon, 2019-01-07 at 14:04 +0100, Henning Schild wrote: > > > From: Henning Schild > > > > > > We should mark the

Re: [PATCHv2] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

On Mon, 2019-01-07 at 14:04 +0100, Henning Schild wrote: > From: Henning Schild > > We should mark the current task as not owning the fpu anymore if it > does > actually own the fpu, not if the fpu itself is active. > > Fixes cb52e6c7438fa > > Reported-by:

Re: [PATCH] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

, not if the fpu itself is active. > > > > Fixes cb52e6c7438fa > > > > Reported-by: Mauro Salvini > > Signed-off-by: Henning Schild > > --- > >   kernel/cobalt/arch/x86/thread.c | 2 +- > >   1 file changed, 1 insertion(+), 1 deletion(-) > > > >

Re: Stack dump on ipipe 4.9.135-7 x86_64

On Fri, 2018-12-21 at 16:11 +0100, Mauro Salvini via Xenomai wrote: > On Fri, 2018-12-21 at 14:51 +0100, Henning Schild wrote: > > Am Thu, 20 Dec 2018 10:10:29 +0100 > > schrieb Jan Kiszka : > > > > > On 20.12.18 09:28, Mauro Salvini via Xenomai wrote: > > >

Re: Stack dump on ipipe 4.9.135-7 x86_64

On Fri, 2018-12-21 at 14:51 +0100, Henning Schild wrote: > Am Thu, 20 Dec 2018 10:10:29 +0100 > schrieb Jan Kiszka : > > > On 20.12.18 09:28, Mauro Salvini via Xenomai wrote: > > > Hi all, > > > > > > I'm testing Xenomai 3 on an Intel Braswell board (At

Stack dump on ipipe 4.9.135-7 x86_64

Hi all, I'm testing Xenomai 3 on an Intel Braswell board (Atom x5-E8000). I'm using ipipe kernel at last commit from [1], branch ipipe-4.9.y, 64bit build on a Debian Stretch 9.6 64bit. Xenomai library is from [2], branch stable/v3.0.x on commit bc53d03f (I haven't two last commits but seems not

Re: rtping differences between master and slaves

On Fri, 2018-11-23 at 13:55 +0100, Jan Kiszka wrote: > On 23.11.18 13:49, Mauro Salvini wrote: > > On Fri, 2018-11-23 at 12:49 +0100, Jan Kiszka wrote: > > > On 23.11.18 11:51, Mauro Salvini via Xenomai wrote: > > > > Hi all, > > > > > > > >

rtping differences between master and slaves

Hi all, I'm trying RTNet (an old version: 0.9.13) on Xenomai (yet another old version, 2.5.6: unluckily I cannot move to newer versions). My setup has 3 identical nodes on isolated RT network: cycle time of 5000us, master with slot offset 0, slave A with slot offset 200us and slave B with slot

[PATCH] copperplate/clockobj: prevent warning with -Wconversion

make cast explicit to avoid warning when user code is compiled with -Wconversion Signed-off-by: Mauro Salvini --- include/copperplate/clockobj.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/copperplate/clockobj.h b/include/copperplate/clockobj.h index 8568794d9

[PATCH] copperplate/clockobj: prevent warning with -Wconversion

make cast explicit to avoid warning when user code is compiled with -Wconversion ---  include/copperplate/clockobj.h | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/copperplate/clockobj.h b/include/copperplate/clockobj.h index 8568794d9..063bcce90 100644 ---

Re: [Xenomai] rt_task_wait_period() does not return -EWOULDBLOCK

On Wed, 2018-04-18 at 20:01 +0530, Pintu Kumar wrote: > On Wed, Apr 18, 2018 at 7:15 PM, Greg Gallagher m> wrote: > > What version was this working in?  I'm assuming you are working out > > of > > stable-3.0.x? If you reverted to an older git commit please post > > the > >

Re: [Xenomai] rt_task_wait_period() does not return -EWOULDBLOCK

On Wed, 2018-04-11 at 16:42 +0200, Philippe Gerum wrote: > On 04/11/2018 04:39 PM, Mauro Salvini wrote: > > On Wed, 2018-04-11 at 16:20 +0200, Philippe Gerum wrote: > > > On 04/11/2018 03:54 PM, Mauro Salvini wrote: > > > > Hi, > > > >

Re: [Xenomai] rt_task_wait_period() does not return -EWOULDBLOCK

On Wed, 2018-04-11 at 16:20 +0200, Philippe Gerum wrote: > On 04/11/2018 03:54 PM, Mauro Salvini wrote: > > Hi, > > > > I'm facing an unexpected behavior of rt_task_wait_period(). > > > > ... > Please try this and let me know if the situation gets any be

[Xenomai] [PATCH] lib/alchemy: fix some documentation lacks

For some functions was not documented that TM_INFINITE and TM_NONBLOCK values could be used as argument. --- lib/alchemy/buffer.c | 20 ++-- lib/alchemy/cond.c | 10 -- lib/alchemy/event.c | 10 +- lib/alchemy/heap.c | 10 +- lib/alchemy/mutex.c | 8

[Xenomai] TM_INFINITE and TM_NONBLOCK not documented for some functions

Hi, reading 3.0.4 API documentation I discovered that for some blocking functions (e.g. rt_sem_p(), rt_mutex_acquire(), rt-event_wait() and relative _until calls) is not documented that TM_INFINITE or TM_NONBLOCK can be passed as timeout argument. Also on master branch sources doxygen code for

Re: [Xenomai] Trying to install Xenomai 3.0.3 on i.MX6 Kernel 4.1.15

ntation and mailing-list. Regards > > Regards > > Cédric > > > > > -Message d'origine- > De : Mauro Salvini [mailto:mauro.salv...@smigroup.net] > Envoyé : lundi 20 mars 2017 15:44 > À : Cédric Perles > Cc : xenomai@xenomai.org > Objet : Re

Re: [Xenomai] Trying to install Xenomai 3.0.3 on i.MX6 Kernel 4.1.15

- Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La > Roche sur Yon Cedex (France) > > Tel : +33 (0)2 51 45 05 31 > > > > www.sepro-group.com <http://www.sepro-group.com/fr> | twitter@SeproGroup > <https://twitter.

Re: [Xenomai] Trying to install Xenomai 3.0.3 on i.MX6 Kernel 4.1.15

On Mon, 2017-03-20 at 08:52 +0100, Cédric Perles wrote: > Hi community, > > > > I’m a Xenomai newby and I’m trying to install Xenomai 3.0.3 on my i.MX6 > based board (kernel 4.1.15 from NXP). > > > > So I followed the “Installing Xenomai 3.x” chapter in Xenomai.org site and > began to

Re: [Xenomai] Set CPU Clock Frequency

Another way to do this is to configure kernel with CPU_FREQ on and with all frequency governors disabled except the performance one, or if you prefer with all governors enabled and performance one set as default governor (instead on-demand). Kernel will boot with default frequency and will change

Re: [Xenomai] Porting Xenomai on iMX6SX

On Mon, 2017-02-06 at 15:28 +0100, Philippe Gerum wrote: > On 02/06/2017 09:29 AM, Mauro Salvini wrote: > > On Thu, 2017-02-02 at 10:52 +0100, Philippe Gerum wrote: > >> On 02/01/2017 10:00 AM, Mauro Salvini wrote: > > I restarted my tests from scratch: my current situation

Re: [Xenomai] Porting Xenomai on iMX6SX

On Thu, 2017-02-02 at 10:52 +0100, Philippe Gerum wrote: > On 02/01/2017 10:00 AM, Mauro Salvini wrote: > > Hi, > > I'm trying to use an iMX6SX custom board with Xenomai. > > I'm able to patch the 4.1 kernel from Freescale community (based on > > 4.1.15_1.2.0 branch fro

[Xenomai] Porting Xenomai on iMX6SX

Hi, I'm trying to use an iMX6SX custom board with Xenomai. I'm able to patch the 4.1 kernel from Freescale community (based on 4.1.15_1.2.0 branch from NXP and merged with 4.1.y branch from mainline) with some little rejections resolved by hand. Kernel boots but Xenomai tests point out some weird

Re: [Xenomai] ARM L2C-310 cahce controller enabling

verwritten in __l2c_init() call), will need a code edit to disable write-allocate. Regards Mauro On Tue, 2017-01-31 at 10:34 +0100, Philippe Gerum wrote: > On 01/31/2017 09:28 AM, Mauro Salvini wrote: > > Hi, > > sorry, found myself the answer here: > > > > http://git.xenoma

Re: [Xenomai] ARM L2C-310 cahce controller enabling

Hi, sorry, found myself the answer here: http://git.xenomai.org/ipipe.git/commit/?h=ipipe-4.1.y=a2a9a6148449095fa658a6d0d0cbed3308be2cfb So, should be L2 cache disabled for iMX6SX (that has a single core)? Thanks again, regards Mauro On Tue, 2017-01-31 at 09:17 +0100, Mauro Salvini wrote

[Xenomai] ARM L2C-310 cahce controller enabling

Hi, I'm working on a iMX6SX custom platform and I'm trying to use Xenomai on top of it. In the past, I tried Xenomai on a iMX6SX SabreSD demoboard using kernel branch 4.1.15 from Freescale patched with Xenomai 3.0.1 (some little rejections corrected by hand), and I was able to get a maximum

[Xenomai] Disable L2 write allocate on iMX6q

Hello, I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. First of all I tried kernel 3.0.43 from Xenomai git branch ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test (with manually generated system load like dd, netcat, ssh) shows an average latency of

Re: [Xenomai] Disable L2 write allocate on iMX6q

On Fri, 2014-04-18 at 14:11 +0200, Gilles Chanteperdrix wrote: On 04/18/2014 02:08 PM, Mauro Salvini wrote: On Fri, 2014-04-18 at 13:29 +0200, Gilles Chanteperdrix wrote: On 04/18/2014 12:00 PM, Mauro Salvini wrote: Hello, I'm testing an iMX6q Sabrelite board from Element14