Ashok kumar writes:
> In xenomai I am running two task for 1ms task period for two task
> after a while I get Cpu time limit exceeded (core dumped) in the terminal
> and in the syslog the error message "watchdog triggered -- signalling
> runaway thread"
>
> is there any solution to this problem
Hi, Steve.
Steve Pavao writes:
> I am building Yocto poky linux for an Intel board at head in Master
> branch in Yocto poky, which currently results in a kernel version
> 4.9.61.
I stick to release branches for Poky for my own releases.
Probably not a big deal, as my experience using HEAD on re
Steve Pavao writes:
> Here are my recipes, which work fine, but Cobalt core does not boot. I must
> need something else in my recipe(s).
>
> For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://ipipe-core-4.9.51-x8
Steve Pavao writes:
> Thanks for that tip. That’s what I was thinking I might need to do.
>
> I guess the solution in Yocto terms is to rework my I-PIPE patch
> recipe to not directly apply the I-PIPE patch, but rather to call
> prepare-kernel.sh and allow it to apply the patch, plus do the othe
Am I correct in assuming that when calling rtdm_timer_start(), I should
not be getting multi-second latencies before the first call to the timer
routine? Just checking before I dig in too far.
Thanks.
___
Xenomai mailing list
Xenomai@xenomai.org
https:/
Philippe Gerum writes:
> On 02/09/2018 11:02 AM, Philippe Gerum wrote:
>> On 02/09/2018 12:45 AM, Lowell Gilbert wrote:
>>> Am I correct in assuming that when calling rtdm_timer_start(), I should
>>> not be getting multi-second latencies before the first call to
Lowell Gilbert writes:
> To put it another way, I'm trying to figure out what am I doing wrong in:
> ret = rtdm_timer_start(&pstate.collect.timer, rtdm_clock_read()
> + 1,
>
Lowell Gilbert writes:
> Philippe Gerum writes:
>
>> On 02/09/2018 11:02 AM, Philippe Gerum wrote:
>>> On 02/09/2018 12:45 AM, Lowell Gilbert wrote:
>>>> Am I correct in assuming that when calling rtdm_timer_start(), I should
>>>> not be getting mu
Lange Norbert writes:
> this seems identical to an issue I have. I wanted to start a
> millisecond tick, aligned to seconds, but used the POSIX
> timerfd_settime. Under Linux this works as intendent, under cobalt it
> doesn't.
>
> I expect that the first timeout would be somewhat close to the ca
Lowell Gilbert writes:
> Lowell Gilbert writes:
>
>> Philippe Gerum writes:
>>
>>> On 02/09/2018 11:02 AM, Philippe Gerum wrote:
>>>> On 02/09/2018 12:45 AM, Lowell Gilbert wrote:
>>>>> Am I correct in assuming that when calling rtdm_tim
it, and the file would be used the same for
other chips containing the Cortex A9, so I'm confused about what might
be wrong.
Any pointers would be appreciated.
Thanks.
Be well.
Lowell Gilbert
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Gilles Chanteperdrix writes:
> On 01/07/2014 11:19 PM, Charles Steinkuehler wrote:
>> The single-core A8 on the
>> BeagleBone is good for about 25 uS typical and 80 uS or so worst case
>> latency.
>
> That is really high. On a 720MHz OMAP3, with the latency test running
> with a 100us period, I t
Gilles Chanteperdrix writes:
> On 01/07/2014 08:52 PM, Lowell Gilbert wrote:
>> What I'm hitting at the moment is that gt_setup() is getting called,
>> but twd_timer_setup() hasn't run yet, so the frequency isn't set yet.
>> Both functions are in __cpuinit,
Gilles Chanteperdrix writes:
> No, you do not have to write your own __ipipe_mach_update_tsc(). See:
> https://www.xenomai.org/index.php/I-pipe-core:ArmPorting#High_resolution_counter
I appreciate the help, but I still don't see an implementation
of __ipipe_mach_update_tsc() that I could have us
Gilles Chanteperdrix writes:
> No, every ARM SOC has its own clocks implementation. This is currently
> changing with the switch to device tree, but not all SOCs are
> converted, at least not all of them were last time I checked. Anyway,
> if your SOC uses device tree, adding a clock may simpl
Gregory Dymarek writes:
> To get kernel 3.10.34 to work the ipipe patch needs updating.
> (ipipe-3.8.x does not apply cleanly).
>
> What is the process to release a new ipipe patch for 3.10.34?
>
> Or what is the alternative?
The source control trees are easily available, so there are a lot of
o
Jan Kiszka writes:
> On 2014-03-27 19:24, Philippe Gerum wrote:
>> On 03/27/2014 07:04 PM, Jan Kiszka wrote:
>>> if (unlikely(...)) - locks are generally unlikely to be contended
>>> (unless something is suboptimally designed at the user site).
>>>
>>
>> I'm unsure we really need to take a chan
yogesh garg writes:
> I am using Xenomai to create my kernel module. But I am getting some errors.
> To debug more on issues I want to print Xenomai debug messages("
> *trace_mark*").
> Please help me what I need to configure or enable to see *trace_mark *
> messages.
Is there a particular probl
"Mallik, Udayan (GSFC-5640)" writes:
> I am installing Xenomai-2.6.4 on my Linux box with Linux-3.10.32.
on a PC-type machine, most likely...
Do you have a kernel working with the ipipe extensions before adding
Xenomai?
> I disabled all but the MSI switch (I could not change this one!) under
Hi.
I have a kernel task created with rtdm_task_init(). I can wake it up
from my ioctl handler in non-RT, but not from inside my ISR, which was
hooked with rtdm_irq_request(). I tried it with a semaphore, with an
event, and then with just rtdm_task_unblock(). I'm probably doing
something silly her
Gilles Chanteperdrix writes:
> On Wed, Feb 18, 2015 at 05:03:33PM -0500, Lowell Gilbert wrote:
>> Hi.
>>
>> I have a kernel task created with rtdm_task_init(). I can wake it up
>> from my ioctl handler in non-RT, but not from inside my ISR, which was
>> hooked
Lowell Gilbert writes:
> Gilles Chanteperdrix writes:
>
>> On Wed, Feb 18, 2015 at 05:03:33PM -0500, Lowell Gilbert wrote:
>>> Hi.
>>>
>>> I have a kernel task created with rtdm_task_init(). I can wake it up
>>> from my ioctl handler in non-RT,
Lowell Gilbert writes:
> Gilles Chanteperdrix writes:
>
>> On Wed, Feb 18, 2015 at 05:03:33PM -0500, Lowell Gilbert wrote:
>>> Hi.
>>>
>>> I have a kernel task created with rtdm_task_init(). I can wake it up
>>> from my ioctl handler in non-RT,
Gilles Chanteperdrix writes:
> On Fri, Feb 20, 2015 at 02:38:12PM -0500, Lowell Gilbert wrote:
>> The mailing list stripped my code, so I'll attach it inline.
>
> It does not strip it, it puts it on a server that can be accessed
> with http, so that only the people who
Thanks for the help, even if I'm not making much progress yet.
Gilles Chanteperdrix writes:
> On Tue, Feb 24, 2015 at 06:01:18PM -0500, Lowell Gilbert wrote:
> To have a real basic configuration, you should use Xenomai 2.6.4 and
> with the latest I-pipe patch for Linux 3.14.
Philippe Gerum writes:
> # echo 1024 > /proc/ipipe/trace/back_trace_points
>
> Then run the test. The output of /proc/ipipe/trace/frozen may help in
> figuring out what happens.
I haven't had a chance to look at it yet, but it's in:
http://be-well.ilk.org/~lowell/projects/ipipe.trace.output.t
Lowell Gilbert writes:
> Philippe Gerum writes:
>
>> # echo 1024 > /proc/ipipe/trace/back_trace_points
>>
>> Then run the test. The output of /proc/ipipe/trace/frozen may help in
>> figuring out what happens.
>
> I haven't had a chance to
Philippe Gerum writes:
> Your test code in user-space seems to enable the timing IRQ only for a
> very short time, between the write and read calls to the driver which
> happen in sequence.
>
> Those two interrupts are very close in the time line, i.e. 42 us:
>
> :| +begin 0x9000 -68
Philippe Gerum writes:
> On 02/26/2015 05:38 PM, Lowell Gilbert wrote:
> The new task will be pinned to the CPU running rtdm_task_init() by
> default, which is likely CPU0 as well.
>
> To check this, I would set the global Xenomai affinity to CPU1 before
> starting the test, s
Gilles Chanteperdrix writes:
> On Thu, Feb 26, 2015 at 02:25:13PM -0500, Lowell Gilbert wrote:
>> Philippe Gerum writes:
>>
>> > On 02/26/2015 05:38 PM, Lowell Gilbert wrote:
>> > The new task will be pinned to the CPU running rtdm_task_init() by
>>
Philippe Gerum writes:
> On 02/26/2015 08:25 PM, Lowell Gilbert wrote:
>> Philippe Gerum writes:
>>
>>> On 02/26/2015 05:38 PM, Lowell Gilbert wrote:
>>> The new task will be pinned to the CPU running rtdm_task_init() by
>>> default, which is likely CP
Gilles Chanteperdrix writes:
> On Thu, Feb 26, 2015 at 04:58:06PM -0500, Lowell Gilbert wrote:
>> Gilles Chanteperdrix writes:
>> > So, to be clear, does the ISR run on CPU0 and the thread doing the
>> > reads run on CPU1? If no, does it work if you do it that w
I meant *without* using /proc/xenomai/affinity. Fixed below:
Gilles Chanteperdrix writes:
> Another problem may be in handling the /proc/xenomai/affinity, so
> could you try without using it? Same for isolcpus. If the ISR runs
> on cpu0 and the tasks run on cpu1, an IPI should be sent in
> __xnp
Gilles Chanteperdrix writes:
> Another problem may be in handling the /proc/xenomai/affinity, so
> could you try without using it? Same for isolcpus. If the ISR runs
> on cpu0 and the tasks run on cpu1, an IPI should be sent in
> __xnpod_schedule to wake up the task blocked in read, you can check
Gilles Chanteperdrix writes:
> On Fri, Mar 06, 2015 at 05:58:25PM -0500, Lowell Gilbert wrote:
>> I meant *without* using /proc/xenomai/affinity. Fixed below:
>>
>> Gilles Chanteperdrix writes:
>>
>> > Another problem may be in handling the /proc/xen
Gilles Chanteperdrix writes:
> I am not sure having a gitignore file in the repository is a good
> idea, for instance, it will conflict with the gitignore I already
> had, because not using the same autotools version as Philippe, my
> git status was already filled with tons of autotools files wit
cristian ramos writes:
>I get error -3 when I use int status = rt_sem_p(&semCC_, TM_INFINITE). I
> have seen in the documentation that the possible values are: -EINVAL(-22),
> -EIDRM(43), -EWOULDBLOCK(11), -EINTR(4), -ETIMEDOUT(110), -EPERM(-1),
> somebody know what is meaning -3 values?
#de
"Gilles Chanteperdrix" writes:
> Lopes, Alexandre wrote:
>> Hello,
>>
>> I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and the
>> corresponding ipipe patch to work on an ARM SoC.
>> The device in question is a MitySoM module which is based on the Cyclone V
>> from Altera and co
>> Note that the mail you are replying to is talking about "global timer", not
>> "global clock".
>>
>> --
>> Gilles.
Oops. Sorry; and thanks.
"Lopes, Alexandre" writes:
> @Lowell: Like Gilles mentioned, there are several timers in the
> Cortex A9. At address PERIPH_BASE_
vibnwis writes:
> I am a newbie and I believe code -19 has been asked before.
That is just reporting ENODEV.
It doesn't tell you much, although it usually means a missing timer.
> My system is made of
>
> arch = arm
> board = PandaBoard ES
> Kernel = 3.18.12
> Patch =
> xenomai-3/kernel/cobal
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). I have not run /bin/relax,
mentioned in the manual page, because I don't have such a program and
can't find any re
Philippe Gerum writes:
> On 06/16/2016 04:43 PM, Lowell Gilbert wrote:
>> I have not run /bin/relax,
>> mentioned in the manual page, because I don't have such a program and
>> can't find any reference to it.
>>
>> I am using 3.0.2.
>
>
> /
Gilles Chanteperdrix writes:
> There is one possibility: if your thread runs with the
> SCHED_OTHER/SCHED_WEAK scheduling policy, I would not expect the
> relaxes to trigger anything, as you have been asking for them by
> choosing to use these policies.
Yes, I should have mentioned that topic. I
Gilles Chanteperdrix writes:
>
> Ok. Could you post an example allowing us to reproduce the issue ?
I would be happy to do so.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Gilles Chanteperdrix writes:
> On Mon, Jun 20, 2016 at 01:15:38PM -0400, Lowell Gilbert wrote:
>> Gilles Chanteperdrix writes:
>>
>> > There is one possibility: if your thread runs with the
>> > SCHED_OTHER/SCHED_WEAK scheduling policy, I would not expect the
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 module.
I have updated the tarball with a missing
Philippe Gerum writes:
> You app is missing a call to pthread_setmode_np() for enabling the
> warn-upon-switch bit,
> e.g. calling pthread_set_mode_np(0, PTHREAD_WARNSW, NULL) would enable
> tracing for the calling thread.
My real application has that. My example stripped out everything I could
Lowell Gilbert writes:
> Gilles Chanteperdrix writes:
>> Ok. Could you post an example allowing us to reproduce the issue ?
>
> I can. It took me a little longer than I figured because I had
> accidentally deleted the MODULE_LICENSE. Is it possible to get the
> kernel makef
Lowell Gilbert writes:
> Lowell Gilbert writes:
>
>> Gilles Chanteperdrix writes:
>>> Ok. Could you post an example allowing us to reproduce the issue ?
>>
>> I can. It took me a little longer than I figured because I had
>> accidentally deleted the MO
Hi.
I have a system based on a Cortex A9. When I was running under Xenomai
2.6, I was able to grab interrupts in RTDM. A few months ago, I updated
from a 3.16 Linux kernel and 2.6.4 Xenomai to a 4.1 kernel with 3.0.2
Xenomai. I'm trying to grab the same IRQ now, and the irqchip doesn't
seem to hav
Lowell Gilbert writes:
> I have a system based on a Cortex A9. When I was running under Xenomai
> 2.6, I was able to grab interrupts in RTDM. A few months ago, I updated
> from a 3.16 Linux kernel and 2.6.4 Xenomai to a 4.1 kernel with 3.0.2
> Xenomai. I'm trying to grab the
Philippe Gerum writes:
> On 11/07/2016 11:11 PM, Lowell Gilbert wrote:
>> Lowell Gilbert writes:
>>
>>> I have a system based on a Cortex A9. When I was running under Xenomai
>>> 2.6, I was able to grab interrupts in RTDM. A few months ago, I updated
>&
Cong Monkey writes:
> I have a center server shared by multi user which is assigned sudo
> permission for special cmd when needed.
>
> Is that possible to allow the user to run any self develop rt base
> application(the user will not attack server by this way) without root
> permission?
Not real
> 2017-02-22 3:00 GMT+08:00 Lowell Gilbert :
>> Cong Monkey writes:
>>
>>> I have a center server shared by multi user which is assigned sudo
>>> permission for special cmd when needed.
>>>
>>> Is that possible to allow the user to run any sel
Hi.
I have an application working successfully with Xenomai 3.0.8 on a 4.14
kernel. I use Yocto to build the system; when I tried to move to a newer
version of Yocto, my application hung on trying to become a daemon. This
is happening with the daemon() call (which is what I've used up to now)
and
Philippe Gerum via Xenomai writes:
> On 4/27/19 12:20 AM, Steve Freyder wrote:
>> I think deamonizing in its canonical form of: fork(), let the forked
>> process take over, and then exit() in the parent, is problematic when
>> you have a wrapped main() where the wrappers already initialized the
>
I disabled auto-init to be able to fork my daemon process, but now I
can't open a file, whether it's before or after I call xenomai_init().
What would be doing that? I kind of need a pid file.
Be well.
Lowell Gilbert via Xenomai writes:
> I disabled auto-init to be able to fork my daemon process, but now I
> can't open a file, whether it's before or after I call xenomai_init().
The errno is EPERM.
Philippe Gerum via Xenomai writes:
> Could you try the patch below? Ideally, we should have this in 3.0.9 if this
> improves the situation.
It works for me with auto-init enabled, and solves my file-open problem as well.
Pierre FICHEUX via Xenomai writes:
> Is there a way to get the Xenomai thread "pid" with POSIX API ? I didn't
> see anything in the "thread management" section.
getpid()?
I was trying to update to 3.0.8, and looking at stat or acct in the
sched branch of the proc tree gives me an instant kernel crash, usually
with a null pointer access from a bogus code address, although the
locations aren't always the same. This is without even having my kernel
module or applicatio
Jan Kiszka writes:
> On 29.01.19 22:06, Lowell Gilbert via Xenomai wrote:
>> I was trying to update to 3.0.8, and looking at stat or acct in the
>> sched branch of the proc tree gives me an instant kernel crash, usually
>> with a null pointer access from a bogus code
62 matches
Mail list logo
