* [Xenomai-help] Xenomai stop working
@ 2012-03-08 3:13 ??
2012-03-08 9:14 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: ?? @ 2012-03-08 3:13 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
Hi
I have installed xenomai-2.5.6 on imx53 quick start board with Linux
2.6.35, it works well but stop working when I do some kernel real time task.
When it stop working, system is not totally down, it will be recovered
after about 8~9 minutes, which comes
<dict://key.60705A9F3503084A844B4ABE47E5D62A/regular> regularly. Console
operation is as normal if no IO task and without increasing of timer
interrupt count(cat /proc/interrupt) before xenomai coming back. I have also
tested it with Linux 2.6.38 and xenomai-2.6.0, nothing has changed.
Maybe there are some bugs in my task code, or some misuse of the skin
interface. I need help to get some idea:
1 Is there any situation lead to such case(stalled about 8~9 minutes)?
2 Can ipipe trace and proc information give anything useful, which I have
to get deeper into implements.
[-- Attachment #2: Type: text/html, Size: 3752 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Xenomai stop working
2012-03-08 3:13 [Xenomai-help] Xenomai stop working ??
@ 2012-03-08 9:14 ` Gilles Chanteperdrix
2012-03-09 6:06 ` 马强
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2012-03-08 9:14 UTC (permalink / raw)
To: ??; +Cc: xenomai
On 03/08/2012 04:13 AM, ?? wrote:
> Hi
>
> I have installed xenomai-2.5.6 on imx53 quick start board with Linux
> 2.6.35, it works well but stop working when I do some kernel real time task.
>
> When it stop working, system is not totally down, it will be recovered
> after about 8~9 minutes, which comes
This usually means that the hardware timer is programmed for a too short
delay and wraps instead of ticking right away. You need to increase, in
__ipipe_mach_set_dec for the cpu you use, the minimum delay for which an
irq is triggered.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Xenomai stop working
2012-03-08 9:14 ` Gilles Chanteperdrix
@ 2012-03-09 6:06 ` 马强
2012-03-09 9:11 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: 马强 @ 2012-03-09 6:06 UTC (permalink / raw)
To: 'Gilles Chanteperdrix'; +Cc: xenomai
Hi Gilles,
I have changed mxc_min_delay as follow
mxc_min_delay = ((__ipipe_cpu_freq + 500000) / 1000000) ?: 1;
->
mxc_min_delay = ((__ipipe_cpu_freq + 250000) / 500000) ?: 1;
means make min delay form 1us to 2us, and it seems to work well. I need a longer test to check it out.
Another issue about this change is whether 2us is long enough? In other words, Is 2us a threshold value that due to hardware or an assumed value that make the possibility smaller? if it is the later one, 2us and someone bigger seems not to be a perfect solution.
Thanks for help
Ma Qiang
-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: 2012年3月8日 17:15
To: ??
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Xenomai stop working
On 03/08/2012 04:13 AM, ?? wrote:
> Hi
>
> I have installed xenomai-2.5.6 on imx53 quick start board with Linux
> 2.6.35, it works well but stop working when I do some kernel real time task.
>
> When it stop working, system is not totally down, it will be recovered
> after about 8~9 minutes, which comes
This usually means that the hardware timer is programmed for a too short
delay and wraps instead of ticking right away. You need to increase, in
__ipipe_mach_set_dec for the cpu you use, the minimum delay for which an
irq is triggered.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Xenomai stop working
2012-03-09 6:06 ` 马强
@ 2012-03-09 9:11 ` Gilles Chanteperdrix
2012-03-13 6:32 ` 马强
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2012-03-09 9:11 UTC (permalink / raw)
To: 马强; +Cc: xenomai
On 03/09/2012 07:06 AM, 马强 wrote:
> Hi Gilles,
>
> I have changed mxc_min_delay as follow
> mxc_min_delay = ((__ipipe_cpu_freq + 500000) / 1000000) ?: 1;
> ->
> mxc_min_delay = ((__ipipe_cpu_freq + 250000) / 500000) ?: 1;
> means make min delay form 1us to 2us, and it seems to work well. I need a longer test to check it out.
>
> Another issue about this change is whether 2us is long enough? In other words, Is 2us a threshold value that due to hardware or an assumed value that make the possibility smaller? if it is the later one, 2us and someone bigger seems not to be a perfect solution.
You can try mxc_min_delay = 0xff, since it is what linux does in the
latest release.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Xenomai stop working
2012-03-09 9:11 ` Gilles Chanteperdrix
@ 2012-03-13 6:32 ` 马强
2012-03-13 7:10 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: 马强 @ 2012-03-13 6:32 UTC (permalink / raw)
To: 'Gilles Chanteperdrix'; +Cc: xenomai
Hi, Gilles.
I could not find "mxc_min_delay = 0xff" in linux source tree
and xenomai directory. mxc_min_delay comes from ipipe,
there is also no such statement in latest patch downloaded
from website.
If mxc_min_delay is 0xff, in my system this means 32us for 8MHz
ipipe tsc. For a real time system, It seems a little bit longer.
I used mxc_min_delay=16(2us) to do a test during last weekend,
until now and no stall have happened again. So mxc_min_delay = 0x10
maybe enough for my test CPU, I can't decide which value should be used.
The following code copy from the time.c file that patched by xenomai.
void __ipipe_mach_set_dec(unsigned long delay)
{
if (delay > mxc_min_delay) {
unsigned long tcmp;
if (!timer_is_v2()) {
tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
__raw_writel(tcmp, timer_base + MX1_2_TCMP);
} else {
tcmp = __raw_readl(timer_base + V2_TCN) + delay;
__raw_writel(tcmp, timer_base + V2_TCMP);
}
} else
ipipe_trigger_irq(__ipipe_mach_timerint);
}
My question is whether this function will be interrupted by other high priority interrupts.
--
Ma.
-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: 2012年3月9日 17:11
To: 马强
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Xenomai stop working
You can try mxc_min_delay = 0xff, since it is what linux does in the
latest release.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Xenomai stop working
2012-03-13 6:32 ` 马强
@ 2012-03-13 7:10 ` Gilles Chanteperdrix
0 siblings, 0 replies; 6+ messages in thread
From: Gilles Chanteperdrix @ 2012-03-13 7:10 UTC (permalink / raw)
To: 马强; +Cc: xenomai
On 03/13/2012 07:32 AM, 马强 wrote:
> Hi, Gilles.
>
> I could not find "mxc_min_delay = 0xff" in linux source tree
> and xenomai directory. mxc_min_delay comes from ipipe,
> there is also no such statement in latest patch downloaded
> from website.
>
> If mxc_min_delay is 0xff, in my system this means 32us for 8MHz
> ipipe tsc. For a real time system, It seems a little bit longer.
>
> I used mxc_min_delay=16(2us) to do a test during last weekend,
> until now and no stall have happened again. So mxc_min_delay = 0x10
> maybe enough for my test CPU, I can't decide which value should be used.
Linux uses a similar mechanism for its clock_event_device named
min_delta_ns. In latest releases min_delta_ns is set such that it
corresponds to 0xff ticks. But you are right: this value is too large
for xenomai.
>
> The following code copy from the time.c file that patched by xenomai.
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> if (delay > mxc_min_delay) {
> unsigned long tcmp;
>
> if (!timer_is_v2()) {
> tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
> __raw_writel(tcmp, timer_base + MX1_2_TCMP);
> } else {
> tcmp = __raw_readl(timer_base + V2_TCN) + delay;
> __raw_writel(tcmp, timer_base + V2_TCMP);
> }
> } else
> ipipe_trigger_irq(__ipipe_mach_timerint);
> }
>
> My question is whether this function will be interrupted by other high priority interrupts.
No, this function is called with hardware irqs off.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-13 7:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-08 3:13 [Xenomai-help] Xenomai stop working ??
2012-03-08 9:14 ` Gilles Chanteperdrix
2012-03-09 6:06 ` 马强
2012-03-09 9:11 ` Gilles Chanteperdrix
2012-03-13 6:32 ` 马强
2012-03-13 7:10 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.