Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4

On 10/08/2015 05:47 PM, Gilles Chanteperdrix wrote: > On Thu, Oct 08, 2015 at 05:41:41PM +0200, Philippe Gerum wrote: >> On 10/08/2015 05:17 PM, Lennart Sorensen wrote: >>> On Thu, Oct 08, 2015 at 04:54:07PM +0200, Philippe Gerum wrote: >>>> I could not find

Re: [Xenomai] RTDM SPI Driver for ARM

On 10/16/2015 11:59 AM, Johann Obermayr wrote: > Hello, > > i search a RTDM SPI for the Freescale imx6 ARM Processor. > > i only found "Xenomai RT SPI Driver for Blackfin >

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

On 10/16/2015 05:28 PM, Jan Kiszka wrote: > On 2015-10-16 17:22, Philippe Gerum wrote: >> On 10/16/2015 04:56 PM, Jan Kiszka wrote: >>> On 2015-10-16 16:49, Jan Kiszka wrote: >>>> Hi, >>>> >>>> kill() is currently handled by libcobalt such t

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

On 10/16/2015 04:56 PM, Jan Kiszka wrote: > On 2015-10-16 16:49, Jan Kiszka wrote: >> Hi, >> >> kill() is currently handled by libcobalt such that PIDs <= 0 are >> forwarded to Linux and PIDs > 0 are considered to target only Xenomai >> threads. But what if the user wants to address a regular

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

On 10/16/2015 05:57 PM, Jan Kiszka wrote: > On 2015-10-16 17:31, Philippe Gerum wrote: >> On 10/16/2015 05:28 PM, Jan Kiszka wrote: >>> On 2015-10-16 17:22, Philippe Gerum wrote: >>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote: >>>>> On

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

On 10/16/2015 06:03 PM, Jan Kiszka wrote: > On 2015-10-16 18:00, Philippe Gerum wrote: >> On 10/16/2015 05:57 PM, Jan Kiszka wrote: >>> On 2015-10-16 17:31, Philippe Gerum wrote: >>>> On 10/16/2015 05:28 PM, Jan Kiszka wrote: >>>>> On 2015-10-16 17:22,

Re: [Xenomai] 4.x merge

On 10/20/2015 05:07 PM, Jorge Ramirez Ortiz wrote: > On 10/14/2015 06:16 PM, Jorge Ramirez Ortiz wrote: >> >>> >>> I did push my current state to github. Check out >>> https://github.com/siemens/linux-ipipe >>> branches ipipe-3.19 and -4.0 >> >> >> >> I just noticed -while reusing some of your

Re: [Xenomai] rt_heap_alloc size 0 - syscall 7 denied

On 10/14/2015 02:21 PM, Frederik Bayart wrote: >> On Wednesday, 14 October 2015, 12:43, Philippe Gerum <r...@xenomai.org> >> wrote: >> On 10/14/2015 12:22 PM, Frederik Bayart wrote: >>> Hallo, >>> I'm using xenomai 3.0 on kernel 3.18.20 (64 bit). >>

Re: [Xenomai] rt_heap_alloc size 0 - syscall 7 denied

On 10/14/2015 12:22 PM, Frederik Bayart wrote: > Hallo, > I'm using xenomai 3.0 on kernel 3.18.20 (64 bit). > > When using single block heap, I'm getting memory allocation problem when > calling rt_heap_alloc with size 0. I don't get the error when calling the > function with size used in

Re: [Xenomai] Fwd: Re: Problem that the Linux scheduler is not called for some ms

On 10/07/2015 04:23 PM, Harald Feßl wrote: > Am 07.10.2015 um 11:07 schrieb Philippe Gerum: >> On 10/07/2015 11:01 AM, Johann Obermayr wrote: >>> Am 05.10.2015 um 13:54 schrieb Philippe Gerum: >>>> On 10/05/2015 12:53 PM, Johann Obermayr wrote: >>>>>

Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4

On 10/07/2015 04:25 PM, PRADHAN, MAKARAND (RC-CA) wrote: > Hi All, > > On further experimentation, I still feel that rt_intr_enable may be causing > my user space int handler to jump into secondary domain. > rt_intr_enable() is a secondary domain call, it cannot execute over the primary domain

Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4

On 10/07/2015 08:47 PM, Philippe Gerum wrote: > On 10/07/2015 04:25 PM, PRADHAN, MAKARAND (RC-CA) wrote: >> Hi All, >> >> On further experimentation, I still feel that rt_intr_enable may be causing >> my user space int handler to jump into secondary domain. >> >

Re: [Xenomai] undefined reference to __cobalt_rt_dev_ioctl

On 10/12/2015 09:12 PM, George Broz wrote: > Hi, > > I'm trying to build a 3rd party application (IgH EtherCAT Master) > for Xenomai 3.0 for an Altera ARM (socfpga) board. Linux and Xenomai, > built with tools on the target, are working normally. > > The IgH ECM uses autotools and makes use of

Re: [Xenomai] Mayday issues again

On 07/08/2015 12:31 PM, Jan Kiszka wrote: On 2015-07-07 14:53, Philippe Gerum wrote: On 07/07/2015 11:27 AM, Philippe Gerum wrote: I tested the patch on ARM. Enabling IPIPE_DEBUG_INTERNAL there reveals a bug with the mayday handler now turning hw IRQs on, as a result of relaxing over the low

Re: [Xenomai] Mayday issues again

On 07/08/2015 02:24 PM, Jan Kiszka wrote: On 2015-07-08 13:56, Philippe Gerum wrote: On 07/08/2015 12:31 PM, Jan Kiszka wrote: On 2015-07-07 14:53, Philippe Gerum wrote: On 07/07/2015 11:27 AM, Philippe Gerum wrote: I tested the patch on ARM. Enabling IPIPE_DEBUG_INTERNAL there reveals a bug

Re: [Xenomai] Mayday issues again

On 07/08/2015 03:04 PM, Jan Kiszka wrote: On 2015-07-08 15:00, Philippe Gerum wrote: On 07/08/2015 02:52 PM, Jan Kiszka wrote: On 2015-07-08 14:43, Philippe Gerum wrote: On 07/08/2015 02:33 PM, Jan Kiszka wrote: On 2015-07-08 14:32, Gilles Chanteperdrix wrote: On Wed, Jul 08, 2015 at 02:24

Re: [Xenomai] Mayday issues again

On 07/08/2015 02:33 PM, Jan Kiszka wrote: On 2015-07-08 14:32, Gilles Chanteperdrix wrote: On Wed, Jul 08, 2015 at 02:24:41PM +0200, Jan Kiszka wrote: On 2015-07-08 13:56, Philippe Gerum wrote: On 07/08/2015 12:31 PM, Jan Kiszka wrote: On 2015-07-07 14:53, Philippe Gerum wrote: On 07/07/2015

Re: [Xenomai] Mayday issues again

On 07/07/2015 11:27 AM, Philippe Gerum wrote: - we want the target thread to relax from a safe and sane location. What about the IRQ context which signals the mayday event preempting, e.g. xnthread_relax() prologue, or any kernel code supposed to run in primary mode only? We would have

Re: [Xenomai] Mayday issues again

Hi Jan, On 06/20/2015 04:34 PM, Jan Kiszka wrote: Hi Philippe, the mayday mechanism is causing troubles to me again. First of all, there is a bug /wrt restarting the mayday syscall. We current don't restart on pending signals, thus destroy the register of the interrupted thread that

Re: [Xenomai] Mayday issues again

On 07/07/2015 03:01 PM, Jan Kiszka wrote: On 2015-07-07 14:53, Philippe Gerum wrote: On 07/07/2015 11:27 AM, Philippe Gerum wrote: - we want the target thread to relax from a safe and sane location. What about the IRQ context which signals the mayday event preempting, e.g. xnthread_relax

Re: [Xenomai] Cyclictest in Xenomai-3

On 08/27/2015 04:53 PM, Konstantinos Chalas wrote: Hello everyone, Is there any plans to port cyclictest over at xenomai-3 for the Cobalt kernel? I compiled the original source file from the rt-tests repo my self for xenomai-3,. For reference i used to get around 70 us worst case with the

Re: [Xenomai] timer_create( ) invalid argument

On 08/28/2015 01:49 AM, Gilles Chanteperdrix wrote: On Thu, Aug 27, 2015 at 11:40:48PM +0200, Konstantinos Chalas wrote: Hello, I have been trying to port some code from the Linux Kernel to the Cobalt Kernel, with no success. When trying to call timer_create( ), i am getting the error

Re: [Xenomai] Cyclictest in Xenomai-3

On 08/27/2015 05:55 PM, Konstantinos Chalas wrote: The build command for cyclictest was gcc -Wall -Wno-nonnull -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -march=armv7-a -mfpu=vfp3 -D_GNU_SOURCE -D_REENTRANT -D__COBALT__ -O2 -Wl,@/usr/xenomai/lib/cobalt.wrappers

Re: [Xenomai] Cyclictest in Xenomai-3

On 08/28/2015 02:37 PM, Konstantinos Chalas wrote: Great! Now, it is much better! Thanks for the interest. I have noticed something else, when using clock_nanosleep, there is something wrong going on. Example output with clock_nanosleep: root@beaglebone:~# cyclictest-p 99 -i 250 -n #

Re: [Xenomai] Cyclictest in Xenomai-3

, this is only a timer calibration issue. The strange average value may be an issue in cyclictest since 2147483647 is 2^31-1, which is INT32_MAX. A bit like no sample had been recorded during such run. On 08/28/2015 02:59 PM, Philippe Gerum wrote: On 08/28/2015 02:51 PM, Konstantinos Chalas wrote

Re: [Xenomai] Cyclictest in Xenomai-3

. # latency [-t0] Thanks On 08/28/2015 02:46 PM, Philippe Gerum wrote: On 08/28/2015 02:37 PM, Konstantinos Chalas wrote: Great! Now, it is much better! Thanks for the interest. I have noticed something else, when using clock_nanosleep, there is something wrong going on. Example output

Re: [Xenomai] xenomai/ipipe arm64 port

On 08/25/2015 08:05 PM, Don Mahurin wrote: On Tue, Aug 25, 2015 at 7:08 AM, Philippe Gerum r...@xenomai.org mailto:r...@xenomai.org wrote: This is likely because -rc7 has added checks to sched-* tests which have time-dependent results, so they may not match the expected value

Re: [Xenomai] Cyclictest in Xenomai-3

ing early by a microsecond once due to the incorrect calibration. This does not reveal any malfunction. therefore when casted as unsigned produced 2^64-1. > It works as it should after running autotune. > > Thank you very much for the help, > Konstantinos > > On 08/28/2015 03:22 PM, Philip

Re: [Xenomai] xenomai/ipipe arm64 port

On 09/01/2015 09:11 PM, Jorge Ramirez Ortiz wrote: > On 09/01/2015 02:27 PM, Dmitriy Cherkasov wrote: >> We have seen this before, but so far have not found a way to consistently >> reproduce it. >> >> There are some caveats with the current way context switching is done in >> Xenomai. >> >> On

Re: [Xenomai] xenomai/ipipe arm64 port

On 09/01/2015 09:11 PM, Jorge Ramirez Ortiz wrote: > On 09/01/2015 02:27 PM, Dmitriy Cherkasov wrote: >> We have seen this before, but so far have not found a way to consistently >> reproduce it. >> >> There are some caveats with the current way context switching is done in >> Xenomai. >> >> On

Re: [Xenomai] Current state of Freescale LS1021A Xenomai support

On 08/31/2015 01:10 PM, Bukuli Norbert wrote: > Hello, Everyone! > > I have a few questions about the current state of Freescale LS1021A > SoC and TWR-LS1021A evaluation board support. > > I saw on the website, that the `QorIQ LS1: LS1021' SoC is supported, > but I could not figure out, what

Re: [Xenomai] [xenomai3] fixing the rtcan_raw ioctl argument issue

Hi Wolfgang, On 09/07/2015 09:36 AM, Wolfgang Grandegger wrote: > Hi Philippe, > > Am 04.09.2015 um 18:18 schrieb Philippe Gerum: >> >> We have a problem with CAN control requests piggybacking on struct ifreq >> for passing arguments to the raw driver. This is unsaf

Re: [Xenomai] timer_create( ) example in Xenomai-3

On 09/07/2015 01:53 PM, Konstantinos Chalas wrote: > Hello everyone, > > Does any of you have a working implementation of timer_create( ) in > Xenomai-3? > > According to the documentation /only thread-directed notification is > supported (evp->sigev_notify set to//SIGEV_THREAD_ID//). The thing

Re: [Xenomai] [pull request] xenomai-3/arm64

On 09/02/2015 11:22 PM, Don Mahurin wrote: > Pull request for xenomai-3/arm64, fixing tracing/syscall prints for arm64. > > The following changes since commit ef3d72d9825eb5ce3a75b93b6b4b4104f7c41db0: > > cobalt/arm64: machine.h: use slightly faster ffnz implementation > (2015-06-17 16:09:20

Re: [Xenomai] [PULL 2/2] ipipe-3.18: Stable merges

On 08/27/2015 05:37 PM, Jan Kiszka wrote: > The following changes since commit b115c4094d734e19fa7a96be1bf3958b3d244b8b: > > Revert "ipipe: Register function tracer for direct and exclusive > invocation" (2015-08-27 17:22:39 +0200) > > are available in the git repository at: > >

Re: [Xenomai] timer_create( ) example in Xenomai-3

On 09/09/2015 03:29 PM, Konstantinos Chalas wrote: > For future reference, this is what a working POSIX timer in Xenomai > looks like: > Good you got it working. A few additional hints: > void* print_time (void* args) > { > struct timespec tp; > char buffer [80]; > struct itimerspec

Re: [Xenomai] how to check RT_MUTEX_INFO.owner

On 09/14/2015 02:03 PM, Frederik Bayart wrote: > In the documentation of RT_MUTEX_INFO is described : > RT_TASK owner : Current mutex owner, or null if unlocked. > > But this is not a pointer, so it can't be compared with NULL. Should you > check RT_TASK.handle ? > You should compare the

Re: [Xenomai] Oops message on rtdm_read()

On 09/29/2015 03:10 PM, Michael Smith wrote: > Hi. I'm unclear what I am doing wrong. But I get a oops message when I am > trying to do a read() (RTDM) from user space into my device driver. > > The read function in the driver has been setup as follows: > > .ops = { > .open

Re: [Xenomai] Fwd: Re: Problem that the Linux scheduler is not called for some ms

On 09/29/2015 02:38 PM, Johann Obermayr wrote: > Am 25.09.2015 um 10:44 schrieb Harald Feßl: >> Hi >> >> I have done a ipipe trace for some working and one non working cycle. >> The trace is stopped after the non working cycle. >> I have marked the working cycles with green and the non working

Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4

On 09/29/2015 06:04 PM, PRADHAN, MAKARAND (RC-CA) wrote: >> Are you playing with the T_LOCK bit? > > Yes. We do T_LOCK to lock the scheduler while we are in a critical section. > Is that why the scheduler does not kick in immediately after the HW int? If the IRQ happens while some task holds

Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4

On 09/29/2015 05:35 PM, PRADHAN, MAKARAND (RC-CA) wrote: > Hi Everyone, > > I am noticing a delay of around 1ms from the time I get an interrupt and the > time when the user space irq handler task is invoked by Xenomai. Would highly > appreciate any suggestions that will help me resolve the

Re: [Xenomai] Xenomai and RT Preempt Patch?

On 09/30/2015 01:47 PM, Jens Köhler wrote: > Hello, > > I have an application which uses Xenomai together with RTnet and a 2nd > application which uses RT preempt patch. I like to run both applications at > same computer. > > Is it possible to install Xenomai and RT preempt patch at same linux >

Re: [Xenomai] xenomai/ipipe arm64 port

On 10/03/2015 12:01 PM, Philippe Gerum wrote: > On 10/03/2015 11:53 AM, Philippe Gerum wrote: >> >> Hi Dmitriy, >> >> On 10/02/2015 10:18 PM, Dmitriy Cherkasov wrote: >>> The following changes since commit >>> 17095784c6d3d44dc7f1512ffab9bb957e2984

Re: [Xenomai] xenomai/ipipe arm64 port

Hi Dmitriy, On 10/02/2015 10:18 PM, Dmitriy Cherkasov wrote: > The following changes since commit > 17095784c6d3d44dc7f1512ffab9bb957e298466: > > cobalt/arm64: leave mm tracking to the pipeline (2015-09-17 15:08:34 > +0200) > > are available in the git repository at: > >

Re: [Xenomai] Cyclictest in Xenomai-3

On 10/03/2015 11:35 AM, 林展翔 wrote: > Hello, > > I've cloned the code from Konstantinos's github page and amended the > Makefile and cyclictest.c like Philippe had suggested. > > But when I ran cyclictest(after compilation) with the command './cyclictest > -p 99 -i 250 -n', the MAX latency was

Re: [Xenomai] xenomai/ipipe arm64 port

On 10/03/2015 11:53 AM, Philippe Gerum wrote: > > Hi Dmitriy, > > On 10/02/2015 10:18 PM, Dmitriy Cherkasov wrote: >> The following changes since commit >> 17095784c6d3d44dc7f1512ffab9bb957e298466: >> >> cobalt/arm64: leave mm tracking to the pi

Re: [Xenomai] Cyclictest in Xenomai-3

On 10/03/2015 11:35 AM, 林展翔 wrote: > Hello, > > I've cloned the code from Konstantinos's github page and amended the > Makefile and cyclictest.c like Philippe had suggested. > > But when I ran cyclictest(after compilation) with the command './cyclictest > -p 99 -i 250 -n', the MAX latency was

Re: [Xenomai] Xenomai tests

On 09/21/2015 02:15 PM, vibnwis wrote: > Having managed to compile Xenomai apps and libs, I went to install them on > target. The way I installed is by creating a xenomai directory in /usr and > set PATH to /usr/xenomai/bin, /usr/xenomai/lib etc. > However, when I ran latency I got this error

Re: [Xenomai] Reg: Linux OOps

On 09/16/2015 04:15 PM, Sureshvs wrote: > Hi > > ARCH=powerPC > Processor: MPC8641 > Linux Kernel : 3.10.32 > Xenomai patch version: xenomai-2.6.3 > > We are getting the below oops randomly.kindly help us to isolate the problem > with the stack trace given below. > > > Oops: Kernel access of

Re: [Xenomai] powerpc 440 userspace latency test does nothing

On 12/05/2015 07:53 PM, Steven Seeger wrote: > More info on this. > > timer_gettime() on latency's timerfd returns 0 seconds and 1 nanosecond, > indicating the timer has not expired. This value usually indicates an expired but not yet handled timer shot; that would match your description of an

Re: [Xenomai] powerpc 440 userspace latency test does nothing

. lockups, unexpected hangs). > ____ > From: Philippe Gerum [r...@xenomai.org] > Sent: Sunday, December 06, 2015 10:48 AM > To: Seeger, Steven D. (GSFC-444.0)[Embedded Flight Systems, Inc]; > xenomai@xenomai.org > Subject: Re: [Xenomai] powerpc

Re: [Xenomai] powerpc 440 userspace latency test does nothing

On 12/06/2015 04:46 AM, Steven Seeger wrote: > I went ahead and used the ipipe-core-3.14.39-powerpc-8 patch and built the > vendor's 3.14.2 kernel against it. I didn't have to do as much work as I did > with the 3.18.20 patch. I had the same results (both with latency and with > freezing.) > >

Re: [Xenomai] Possible sync problem with timerfd and application

On 12/17/2015 03:07 PM, Umair Ali wrote: > Hello there, > > I am using the timerfd to produce the required sleep function for sending the > raw ethernet packets using rtnet driver periodically. I read the file using > the mmap() function and mlockall(MCL_CURRENT|MCL_FUTURE). My code is attached

Re: [Xenomai] SMAP-detected direct userspace access

On 12/18/2015 05:23 PM, Jan Kiszka wrote: > Hi all, > > I know this is legacy code, but this is where we currently stumbled into > it, and maybe the same pattern also exists in 3.x: > > http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182 > > more precisely: > >

[Xenomai] Ports to BCM2708, BCM2709

Hi, There has been a significant traffic on the list about ongoing port(s) to the Broadcom 2709 processor family, so it seems the right time to contribute some related code that has been brewing here for a couple of weeks, targeting the BCM2708 family. At git://git.xenomai.org/ipipe.git, branch

Re: [Xenomai] userspace absolute timer value

On 12/15/2015 02:19 AM, Steven Seeger wrote: > Since my last post I seem to have solved the issues with my ppc44x board hard > locking up. I've relayed this info to Philippe and hopefully he will confirm > that I'm correct and that I should make a patch. Confirmed, the bug is real and ugly, the

Re: [Xenomai] Alchemy periodic task and timer overruns

On 11/30/2015 01:09 PM, Gilles Chanteperdrix wrote: > On Mon, Nov 30, 2015 at 11:57:49AM +0100, Registrierungen wrote: >> Hello, >> >> i've got a problem using the periodic tasks. >> I am using the alchemy tasks running 10kHz and i get a lot of (up ~ >> 10) timer overruns / sek calling

Re: [Xenomai] multiple failing writes to XDDP socket seem to block other I/Os

On 11/17/2015 11:34 AM, Thierry Bultel wrote: > Hi, > > With xenomai-2.6.4 on IMX6, I am facing an issue, that for now, and > unfortunately, I have not been able to > narrow down to a simple test case, but I am still working on it. > > Considering the following piece of code, where : > > -

Re: [Xenomai] registry

On 11/21/2015 06:53 AM, Mathieu Rondonneau wrote: > Hi, > > When a skin (lets say vxworks for example) does a > registry_add_dir("/vxworks"), where this directory gets created? > > I can see the registry as follow: > /var/run/xenomai/root/ > /var/run/xenomai/system/heaps >

Re: [Xenomai] Test program not accessing RTDM driver

On 01/12/2016 04:43 PM, Heinick, J Michael wrote: -Original Message- From: Philippe Gerum [mailto:r...@xenomai.org] Sent: Monday, January 11, 2016 9:54 AM To: Heinick, J Michael; xenomai@xenomai.org Subject: Re: [Xenomai] Test program not accessing RTDM driver On 01/11/2016 03:33 PM

Re: [Xenomai] XDDP NRT to RT communication and select

On 06/08/2016 11:56 AM, Alex Plits wrote: > > >> -Original Message----- >> From: Philippe Gerum [mailto:r...@xenomai.org] >> Sent: Thursday, June 02, 2016 4:12 PM >> To: Alex Plits; xenomai@xenomai.org >> Subject: Re: [Xenomai] XDDP NRT to RT communicati

Re: [Xenomai] Activate a task with an alarm

On 06/08/2016 02:12 PM, Mathieu KOWALEWSKI wrote: > > > Hey, > > I'm trying to create a alarm that can activate a alarm > handler or a task ... > > But when my handler spawn a task, it returns an > EINVAL error. > > I use Alchemy (Native) API and the Cobalt kernel on > Xenomai 3.0.2 with

Re: [Xenomai] what limits number of pSOS tasks using t_create?

On 06/08/2016 11:11 AM, Marcel Van Mierlo wrote: > root@WPL:/var/wpl# ./wpl.bin --dump-config > based on Xenomai/cobalt v3.0 -- #5f6b32f (2015-10-31 20:57:40 +0100) Before anything else, could you rebase your tests over the stable-3.0.x branch from our git tree? The version you have been testing

Re: [Xenomai] what limits number of pSOS tasks using t_create?

On 06/09/2016 02:45 PM, Marcel Van Mierlo wrote: > OK, yep that sorted it. Thanks. > > MaxThreadsLimit_Pre and MaxThreadsLimit_Post now always succeed, and > MaxThreads(5000) fails consistently on 847 every time (which seems about > right for the parameters I am using). > > root@WPL:/var/wpl#

Re: [Xenomai] Migrating a Xenomai 2.6.4 to a 4.6 kernel

On 06/03/2016 04:20 PM, Jean-Michel Hautbois wrote: > Hi, > > 2016-06-03 16:09 GMT+02:00 Gilles Chanteperdrix < > gilles.chanteperd...@xenomai.org>: > >> On Fri, Jun 03, 2016 at 09:55:34AM -0400, Lennart Sorensen wrote: >>> On Fri, Jun 03, 2016 at 11:13:39AM +0200, Gilles Chanteperdrix wrote:

Re: [Xenomai] what limits number of pSOS tasks using t_create?

Hi, On 06/06/2016 10:14 AM, Marcel Van Mierlo wrote: > > Hi Philippe, yes that worked. > > I made a regression test on the maximum number of psos threads I could > create. I found that once I start seeing ERR_NOTCB returned from t_create the > maximum number of tasks I can create then drops,

Re: [Xenomai] Performance impact after switching from 2.6.2.1 to 2.6.4

m ? > why didn't I see them on Kernel 3.0.43 with Xenomai 2.6.4 ? > how long do they need to process ? > > Is there any dependecy in Xenomai between the kernel version and this > virtual interrupts ? > Maybe you should consider reading all the replies you get: On 05/31/2016 05

Re: [Xenomai] Linux RT driver migrating to 3.0...

On 06/13/2016 03:14 PM, Stephane Grosjean wrote: > Hi! > > Successfully running for years a Xenomai 2.6.x RT driver under some > dual-kernel Linux versions, we'd like to migrate it to Xenomai 3.x. > > First step consisting in compiling the driver is over, time has come to > test it. > >

Re: [Xenomai] RTDM syscalls & switching

On 06/14/2016 07:13 PM, Jan Kiszka wrote: > On 2016-06-14 17:23, Philippe Gerum wrote: >> Restoring the original behavior unconditionally would not be a fix but >> only a work-around for your own issue. Finding a better way acceptable >> to all parties is on my todo list f

Re: [Xenomai] RTDM syscalls & switching

On 06/14/2016 10:03 PM, Jan Kiszka wrote: > On 2016-06-14 21:48, Philippe Gerum wrote: >> On 06/14/2016 05:27 PM, Jan Kiszka wrote: >>> On 2016-06-14 17:23, Philippe Gerum wrote: >>>> On 06/14/2016 05:09 PM, Jan Kiszka wrote: >>>>> On 2016-05-13 17:32,

Re: [Xenomai] RTDM syscalls & switching

On 06/14/2016 05:27 PM, Jan Kiszka wrote: > On 2016-06-14 17:23, Philippe Gerum wrote: >> On 06/14/2016 05:09 PM, Jan Kiszka wrote: >>> On 2016-05-13 17:32, Jan Kiszka wrote: >>>> On 2016-05-13 15:38, Philippe Gerum wrote: >>>>> On 05/13/2016 07:54 AM,

Re: [Xenomai] XDDP NRT to RT communication and select

On 05/11/2016 08:58 AM, Alex Plits wrote: > Hi, > > We require communication between non-real time and real time thread in > xenomai 3.x, so naturally we planned to use > XDDP. > After careful read and looking into examples in smokey we tried to implement > simple communication > Between NRT

Re: [Xenomai] what limits number of pSOS tasks using t_create?

On 05/13/2016 03:27 PM, Marcel Van Mierlo wrote: > Hi, > > > Which parameters limit the number of psos skin tasks that can be created > using t_create()? (ARM (Beagle), Xenomai 3.0). > > At the moment I am getting ERR_NOTCB back after creating about 118 tasks > (just calling t_create not

Re: [Xenomai] Performance impact after switching from 2.6.2.1 to 2.6.4

On 05/31/2016 04:09 PM, Wolfgang Netbal wrote: > Dear all, > > we have moved our application from "XENOMAI 2.6.2.1 + Linux 3.0.43" to > "XENOMAI 2.6.4. + Linux 3.10.53". Our target is an i.MX6DL. The system > is now up and running and works stable. Unfortunately we see a > difference in the

Re: [Xenomai] Xenomai 3 vs 2.6: rtdm_irq_request() calling task context change

On 06/21/2016 11:22 AM, Stephane Grosjean wrote: > Hi, > > https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ says: > > "rtdm_irq_request/free() and rtdm_irq_enable/disable() call pairs must > be called from a Linux task context, which is a restriction that did not > exist previously with

Re: [Xenomai] slackspot

On 06/21/2016 08:59 PM, Lowell Gilbert wrote: > Lowell Gilbert writes: > >> I'm attaching a tar file, but in case this list strips attachments, it's >> also at >> http://be-well.ilk.org/~lowell/example.tar >> It's about a hundred lines each for the application and kernel

Re: [Xenomai] ftrace dispatch function broken on 2.6.5

On 06/18/2016 03:37 PM, Gilles Chanteperdrix wrote: > On Sat, Jun 18, 2016 at 03:21:40PM +0200, Philippe Gerum wrote: >> On 06/18/2016 03:08 PM, Gilles Chanteperdrix wrote: >>> Hi Philippe, >>> >>> it seems since I-pipe commit >>> b115c4094d734e19fa7a

Re: [Xenomai] ftrace dispatch function broken on 2.6.5

On 06/19/2016 07:34 PM, Gilles Chanteperdrix wrote: > On Sun, Jun 19, 2016 at 07:28:43PM +0200, Philippe Gerum wrote: >> On 06/18/2016 03:37 PM, Gilles Chanteperdrix wrote: >>> On Sat, Jun 18, 2016 at 03:21:40PM +0200, Philippe Gerum wrote: >>>> On 06/18/2016 03:08

Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/autotune: Rework autotune_ioctl_nrt/ rt for more robust request handling

On 06/17/2016 07:26 PM, git repository hosting wrote: > Module: xenomai-jki > Branch: for-forge > Commit: 3aa24e314c81d52d8d2e00ce05da9c0e18a698d2 > URL: > http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=3aa24e314c81d52d8d2e00ce05da9c0e18a698d2 > > Author: Jan Kiszka

Re: [Xenomai] ftrace dispatch function broken on 2.6.5

On 06/18/2016 03:08 PM, Gilles Chanteperdrix wrote: > Hi Philippe, > > it seems since I-pipe commit > b115c4094d734e19fa7a96be1bf3958b3d244b8b on the ipipe-3.18 branch: > Revert "ipipe: Register function tracer for direct and exclusive > invocation" > > This reverts commit

Re: [Xenomai] slackspot

On 06/16/2016 04:43 PM, Lowell Gilbert wrote: > I have been unable to use slackspot, because /proc/xenomai/debug/relax > is empty. I do have CONFIG_XENO_OPT_DEBUG_TRACE_RELAX enabled (without > that enabled, I don't even have the file). This is expected. I have not run /bin/relax, > mentioned

Re: [Xenomai] Reg: T2080 BOOK3E_64 Xenomai support

On 06/24/2016 11:57 AM, Sureshvs wrote: > > Hi > > I am using freescale T2080 64bit PowerPC based processor board.Any xenomai > version support is available for BOOK3E_64 based T2080 processor. > > In your website, suported architectures for powerpc mentioned as "BOOK3E_64 > core is not

Re: [Xenomai] Test program not accessing RTDM driver

On 01/11/2016 03:33 PM, Heinick, J Michael wrote: .1.2.3.4.5.6.7| Currently, I have a RTDM driver that installs with insmod, creates the node in /dev/rtdm, uninstalls with rmmod, and removes the node from /dev/rtdm. At this early

Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/kernel: Fix invalidation of cond shadow

On 01/13/2016 07:33 PM, git repository hosting wrote: > Module: xenomai-jki > Branch: for-forge > Commit: b7d37dab571df0c0cd42aae094c3d5d1bc71db80 > URL: > http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=b7d37dab571df0c0cd42aae094c3d5d1bc71db80 > > Author: Jan Kiszka

Re: [Xenomai] VxWorks API on Xenomai 3.0

On 01/14/2016 10:22 AM, Nicolas SCHURANDO wrote: > Hello everyone, > > In an attempt to migrate from Xenomai 2.6.4 on a Raspberry Pi 1 to Xenomai > 3.0.1 on a Raspberry Pi 2, I get an error when trying to spawn a VxWorks > task in a fairly simple test program. Here is the output : > >

Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/kernel: Fix invalidation of cond shadow

On 01/13/2016 08:42 PM, Jan Kiszka wrote: > On 2016-01-13 19:44, Philippe Gerum wrote: >> On 01/13/2016 07:33 PM, git repository hosting wrote: >>> Module: xenomai-jki >>> Branch: for-forge >>> Commit: b7d37dab571df0c0cd42aae094c3d5d1bc71db80 >>> U

Re: [Xenomai] VxWorks API on Xenomai 3.0

On 01/18/2016 01:34 PM, Nicolas SCHURANDO wrote: > Hi Philippe, > > In your previous message you suggested that something might be wrong > with the way the application is initialized. And my message was an > attempt at further describing what I had already done. > > Oh, I see. I suppose the

Re: [Xenomai] Xenomai-3.0.1 inter-process rt_queue_receive segfault

On 01/17/2016 05:48 PM, Philippe Gerum wrote: > On 01/15/2016 05:34 PM, Thomas Axelsson wrote: >> Hi, >> >> We are trying to use Alchemy RT Message Queues between two different >> processes in Xenomai 3.0.1. However, our receiving process segfaults >> when it

Re: [Xenomai] VxWorks API on Xenomai 3.0

On 01/15/2016 10:57 AM, Nicolas SCHURANDO wrote: > Hi Philippe, > > Thank your for your answer. I have read the manual page entitled > "Application setup and init", and in particular the part about manual vs > automatic bootstrap, and I have tried to follow the instructions to the > letter. > >

Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/kernel: Fix invalidation of cond shadow

On 01/15/2016 02:59 PM, Jan Kiszka wrote: > On 2016-01-14 09:46, Philippe Gerum wrote: >> On 01/13/2016 08:42 PM, Jan Kiszka wrote: >>> On 2016-01-13 19:44, Philippe Gerum wrote: >>>> On 01/13/2016 07:33 PM, git repository hosting wrote: >>>>>

Re: [Xenomai] Xenomai-3.0.1 inter-process rt_queue_receive segfault

On 01/15/2016 05:34 PM, Thomas Axelsson wrote: > Hi, > > We are trying to use Alchemy RT Message Queues between two different > processes in Xenomai 3.0.1. However, our receiving process segfaults > when it receives a message. Using gdb, we see that the SIGSEGV occurs in >

Re: [Xenomai] ipipe x86_64 huge page ioremap

On 01/14/2016 06:34 PM, Henning Schild wrote: > Hey, > > the 4.1 kernel supports mapping IO memory using huge pages. > 0f616be120c632c818faaea9adcb8f05a7a8601f .. > 6b6378355b925050eb6fa966742d8c2d65ff0d83 > > In ipipe memory that gets ioremapped will get pinned using >

Re: [Xenomai] Process shared rt_event_wait() never signaled on ARM with Mercury core

On 02/10/2016 07:41 PM, Charles Kiorpes wrote: > Hello, > I am having some difficulty getting two processes to signal each other on > an AM572x EVM. > I have two small sample applications: > > - app1 : creates an event "MYTEST" using rt_event_create(), clears the > event, and then

Re: [Xenomai] Mercury / pSOS: messages lost due to bug in q_receive

On 02/05/2016 09:27 AM, Ronny Meeus wrote: > Hello > > we are using the pSOS interface on top of the Mercury core. > Under heavy stress conditions we see sporadically that messages are > getting lost. > > Attached you find a test application (multi_queue.c) that helped me > to find the issue

Re: [Xenomai] Process shared rt_event_wait() never signaled on ARM with Mercury core

On 02/11/2016 01:57 PM, Charles Kiorpes wrote: > > I attempted to run several tests: 'task-1', 'event-1', and 'mutex-1'. > Each of these hung indefinitely. A gdb trace indicated that they were > hanging on __libc_do_syscall() within __pthread_cond_wait() within > threadobj_cond_wait(). > > I

Re: [Xenomai] Process shared rt_event_wait() never signaled on ARM with Mercury core

On 02/11/2016 01:57 PM, Charles Kiorpes wrote: > will be trying combinations of kernels and configuration options > throughout the course of the day. > The embedded-specific options in the kernel configuration (CONFIG_EMBEDDED) should be checked, particularly CONFIG_FUTEX. -- Philippe.

Re: [Xenomai] Process shared rt_event_wait() never signaled on ARM with Mercury core

On 02/12/2016 03:08 PM, Charles Kiorpes wrote: > > > On Fri, Feb 12, 2016 at 5:43 AM, Philippe Gerum <r...@xenomai.org > <mailto:r...@xenomai.org>> wrote: > > On 02/11/2016 01:57 PM, Charles Kiorpes wrote: > > > > I attempted to run several

Re: [Xenomai] Mercury / pSOS: messages lost due to bug in q_receive

On 02/10/2016 09:13 AM, Ronny Meeus wrote: > On Wed, Feb 10, 2016 at 7:06 AM, Ronny Meeus wrote: >> On Tue, Feb 9, 2016 at 9:23 PM, Ronny Meeus wrote: >> >>> Philippe >>> >>> I have ported the patch to our version of Xenomai and started the test. >>>

Re: [Xenomai] Mercury / pSOS: messages lost due to bug in q_receive

On 02/10/2016 07:06 AM, Ronny Meeus wrote: > On Tue, Feb 9, 2016 at 9:23 PM, Ronny Meeus wrote: > >> Philippe >> >> I have ported the patch to our version of Xenomai and started the test. >> It runs already for several minutes without issues so it looks like >> the problem

Re: [Xenomai] [PATCH v2] ipipe x86 mm: handle huge pages in memory pinning

On 01/28/2016 09:53 PM, Henning Schild wrote: > On Thu, 28 Jan 2016 11:53:08 +0100 > Philippe Gerum <r...@xenomai.org> wrote: > >> On 01/27/2016 02:41 PM, Henning Schild wrote: >>> In 4.1 huge page mapping of io memory was introduced, enable ipipe >>> to

<    4   5   6   7   8   9   10   11   12   13   >