Re: [Xenomai-help] rt_task crash kernel

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

No I have not a JTAG probe.

But I found that the system crashes when the xnlock_put_irqrestore function
is called in the task.c file at (in rt_task_create function).

Thanks

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mardi, 2. octobre 2007 14:29
À : Patrick
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/2/07, Patrick <kpa_info@domain.hid> wrote:
> > -----Message d'origine-----
> > De: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> > Envoyé: mardi, 2. octobre 2007 11:46
> > À: Patrick
> > Cc: xenomai-core
> > Objet: Re: [Xenomai-help] rt_task crash kernel
> >
> > On 10/2/07, Patrick <kpa_info@domain.hid> wrote:
> > >
> > >
> > >
> > >
> > > Yes, I have tried with bin/latency user space application and the
system
> > > crashes.
> >
> > latency appears to crash on ARM when launched with the default 100us
> > period, the system is just too busy. Do you observe the crash with a 1
> > ms period ?
>
> Yes, I have tried with latency -p 1000 and the issues is the same.

Ok, so I-pipe for PXA has a problem. Next question: do you have a JTAG probe
?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
>
> No I have not a JTAG probe.
>
> But I found that the system crashes when the xnlock_put_irqrestore function
> is called in the task.c file at (in rt_task_create function).

Ok, next step is to put a printk (or better a printascii) in the tick
handler to check if the timer interrupt is ticking ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> Ok, but where is the tick handler?

ksrc/nucleus/intr.c, function xnintr_clock_handler.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

Yes, the timer work !

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mercredi, 3. octobre 2007 09:22
À : Patrick
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
>
> No I have not a JTAG probe.
>
> But I found that the system crashes when the xnlock_put_irqrestore
function
> is called in the task.c file at (in rt_task_create function).

Ok, next step is to put a printk (or better a printascii) in the tick
handler to check if the timer interrupt is ticking ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> Yes, the timer work !

Even when the system seems to be locked up when running latency ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

It's not possible to test this case because adding printk in tick handler
saturates the console with messages and it's impossible to work and the
target boot very, very slow. 

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mercredi, 3. octobre 2007 10:45
À : Patrick
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> Yes, the timer work !

Even when the system seems to be locked up when running latency ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> It's not possible to test this case because adding printk in tick handler
> saturates the console with messages and it's impossible to work and the
> target boot very, very slow.

You can do something like:

static int ticks;

if (!(++ticks % 1000))
    printk("%d ticks\n", ticks);

Which will only print something once every 1000 ticks.

>
> -----Message d'origine-----
> De: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Envoyé: mercredi, 3. octobre 2007 10:45
> À: Patrick
> Cc: xenomai@xenomai.org
> Objet: Re: [Xenomai-help] rt_task crash kernel
>
> On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> > Yes, the timer work !
>
> Even when the system seems to be locked up when running latency ?
>
> --
>                                                Gilles Chanteperdrix
>
>


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

Ok, some messages occur on the console with latency.

For information I have successfully installed and used Xenomai 2.3.1 with
2.6.15 kernel on the same board. 

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mercredi, 3. octobre 2007 14:19
À : Patrick
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> It's not possible to test this case because adding printk in tick handler
> saturates the console with messages and it's impossible to work and the
> target boot very, very slow.

You can do something like:

static int ticks;

if (!(++ticks % 1000))
    printk("%d ticks\n", ticks);

Which will only print something once every 1000 ticks.

>
> -----Message d'origine-----
> De: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Envoyé: mercredi, 3. octobre 2007 10:45
> À: Patrick
> Cc: xenomai@xenomai.org
> Objet: Re: [Xenomai-help] rt_task crash kernel
>
> On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> > Yes, the timer work !
>
> Even when the system seems to be locked up when running latency ?
>
> --
>                                                Gilles Chanteperdrix
>
>


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
> Ok, some messages occur on the console with latency.

Continuously, or does it stop ? If the timer is still ticking, it is
surprising that latency does not print anything. If the timer stops,
then we have a problem. You may also want to enable all Xenomai/I-pipe
debugging options in order to see if it prints something before
locking up.

>
> For information I have successfully installed and used Xenomai 2.3.1 with
> 2.6.15 kernel on the same board.

But for the 2.6.15, you had no EABI, have you tried compiling the
v2.3.4 without EABI ? Another thing that you could try is to compile
v2.3.4 with the patch
http://download.gna.org/adeos/patches/v2.6/arm/older/adeos-ipipe-2.6.20-arm-1.7-02.patch.

This patch was the last patch before reworking the tsc emulation,
knowing whether it works could help find what part of the patch is
causing the issue you observe.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

The timer is ticking but stops after some times

I have enabled all debug options in menuconfig but no message is printed
before the crash.

I try to patch new kernel with 2.6.20-arm-1.7-02 patch but is the same.

 

For the 2.6.15 kernel I hadn’t eabi toolchain and the kernel was not
compiled with eabi. 

For 2.6.20 kernel I have an eabi toolchain and the kernel is compiled with
eabi. 

 

In yours PXA270 board 2.6.20 kernel with xenomai 2.3.4 works?

 

Thank’s

 

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mercredi, 3. octobre 2007 15:43
À : Patrick
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] rt_task crash kernel

 

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:

> Ok, some messages occur on the console with latency.

 

Continuously, or does it stop ? If the timer is still ticking, it is

surprising that latency does not print anything. If the timer stops,

then we have a problem. You may also want to enable all Xenomai/I-pipe

debugging options in order to see if it prints something before

locking up.

 

> 

> For information I have successfully installed and used Xenomai 2.3.1 with

> 2.6.15 kernel on the same board.

 

But for the 2.6.15, you had no EABI, have you tried compiling the

v2.3.4 without EABI ? Another thing that you could try is to compile

v2.3.4 with the patch

http://download.gna.org/adeos/patches/v2.6/arm/older/adeos-ipipe-2.6.20-arm-
1.7-02.patch.

 

This patch was the last patch before reworking the tsc emulation,

knowing whether it works could help find what part of the patch is

causing the issue you observe.

 

-- 

                                               Gilles Chanteperdrix


[-- Attachment #2: Type: text/html, Size: 7336 bytes --]

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
>
>
>
>
> The timer is ticking but stops after some times
>
> I have enabled all debug options in menuconfig but no message is printed
> before the crash.
>
> I try to patch new kernel with 2.6.20-arm-1.7-02 patch but is the same.

Ok. So the bug is not in the tsc emulation rework.

>
>
>
> For the 2.6.15 kernel I hadn't eabi toolchain and the kernel was not
> compiled with eabi.
>
> For 2.6.20 kernel I have an eabi toolchain and the kernel is compiled with
> eabi.

It would be nice if you could try with the no eabi toolchain.

>
>
>
> In yours PXA270 board 2.6.20 kernel with xenomai 2.3.4 works?

I do not have a PXA270 board, I test the patch on AT91.
I sent a mail around 1.7-05 asking people to test the patch on their
box and report, but did not receive an answer about the PXA board, so
I am afraid you are the first to ever test the new patch on PXA.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

Hi,

I have tryed to compile the 2.6.20 kernel without eabi but the issue is the
same: the kernel crashes when I insert the module.

Thanks for your help.

Patrick

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mercredi, 3. octobre 2007 17:13
À : Patrick
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/3/07, Patrick <kpa_info@domain.hid> wrote:
>
>
>
>
> The timer is ticking but stops after some times
>
> I have enabled all debug options in menuconfig but no message is printed
> before the crash.
>
> I try to patch new kernel with 2.6.20-arm-1.7-02 patch but is the same.

Ok. So the bug is not in the tsc emulation rework.

>
>
>
> For the 2.6.15 kernel I hadn't eabi toolchain and the kernel was not
> compiled with eabi.
>
> For 2.6.20 kernel I have an eabi toolchain and the kernel is compiled with
> eabi.

It would be nice if you could try with the no eabi toolchain.

>
>
>
> In yours PXA270 board 2.6.20 kernel with xenomai 2.3.4 works?

I do not have a PXA270 board, I test the patch on AT91.
I sent a mail around 1.7-05 asking people to test the patch on their
box and report, but did not receive an answer about the PXA board, so
I am afraid you are the first to ever test the new patch on PXA.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

Patrick wrote:
 > Hi,
 > 
 > I have tryed to compile the 2.6.20 kernel without eabi but the issue is the
 > same: the kernel crashes when I insert the module.
 > 
 > Thanks for your help.

Ok, so I have not broken the EABI stuff.

From now on, if you want to work with this new patch, you will have to
debug it yourself. Of course, we will provide some help on this list.

There are two ways you can go:
- either you bisect in the Adeos patches to see which patch introduced
  the bug (all I-pipe patches should work with Xenomai v2.3.4, except
  specifically 1.7-05);
- either you try and debug the crash. Hopefully, the kernel tries to
  print something before it dies, so what you can do is modify printk so
  that it does a vsnprintf and uses the printascii function (in order to
  have a working printascii, you have to enable low-level debugging
  functions in the kernel configuration "kernel hacking"
  section). Then, if you succeed, you will have to try to use the tracer
  to understand what happens.

This reminds me, last time we solved such a bug on ARM, the "schedule"
function ended up called in a loop in Xenomai domain. To detect this,
enable I-pipe debugging in kernel configuration and select the "Check
for illicit cross-domain calls" option.

Good luck if you decide to debug this new patch.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

I have tried to compile Xenomai 2.3.2 with adeos patch 1.7-03 but the system
doesn't boot correctly. If I disable RealTime subsystem in kernel
configuration the system boots right.

I have tried to compile Xenomai 2.3.4 with adeos patch 1.7-01. The system
boots but when I insert my module the system crashes. Exactly like with the
1.7-06.

So I think that the bug is not in adeos patch but in Xenomai ?!?

Thanks

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : jeudi, 4. octobre 2007 21:24
À : Patrick
Cc : xenomai@xenomai.org
Objet : RE: [Xenomai-help] rt_task crash kernel

Patrick wrote:
 > Hi,
 > 
 > I have tryed to compile the 2.6.20 kernel without eabi but the issue is
the
 > same: the kernel crashes when I insert the module.
 > 
 > Thanks for your help.

Ok, so I have not broken the EABI stuff.

>From now on, if you want to work with this new patch, you will have to
debug it yourself. Of course, we will provide some help on this list.

There are two ways you can go:
- either you bisect in the Adeos patches to see which patch introduced
  the bug (all I-pipe patches should work with Xenomai v2.3.4, except
  specifically 1.7-05);
- either you try and debug the crash. Hopefully, the kernel tries to
  print something before it dies, so what you can do is modify printk so
  that it does a vsnprintf and uses the printascii function (in order to
  have a working printascii, you have to enable low-level debugging
  functions in the kernel configuration "kernel hacking"
  section). Then, if you succeed, you will have to try to use the tracer
  to understand what happens.

This reminds me, last time we solved such a bug on ARM, the "schedule"
function ended up called in a loop in Xenomai domain. To detect this,
enable I-pipe debugging in kernel configuration and select the "Check
for illicit cross-domain calls" option.

Good luck if you decide to debug this new patch.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/5/07, Patrick <kpa_info@domain.hid> wrote:
> I have tried to compile Xenomai 2.3.2 with adeos patch 1.7-03 but the system
> doesn't boot correctly. If I disable RealTime subsystem in kernel
> configuration the system boots right.
>
> I have tried to compile Xenomai 2.3.4 with adeos patch 1.7-01. The system
> boots but when I insert my module the system crashes. Exactly like with the
> 1.7-06.
>
> So I think that the bug is not in adeos patch but in Xenomai ?!?

We already knew that 1.7-02 did not work, so testing 1.7-03 was
useless. Please do not use your module to test, use latency -p 1000.

Now, you also know that I-pipe 2.6.15-1.5-08 works.
Instead of trying the patches one after the other, you should try to
do it the same was as a bisection (dichotomie en francais). That is,
when you have a version n that works and version m that does not work,
try version (n+m)/2. This will converge much faster.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] rt_task crash kernel

[Patrick]

-----Message d'origine-----
De : Patrick [mailto:kpa_info@domain.hid
Envoyé : mardi, 2. octobre 2007 12:46
À : 'Gilles Chanteperdrix'
Objet : RE: [Xenomai-help] rt_task crash kernel

Yes, I have tried with latency -p 1000 and the issues is the same.

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : mardi, 2. octobre 2007 11:46
À : Patrick
Cc : xenomai-core
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/2/07, Patrick <kpa_info@domain.hid> wrote:
>
>
>
>
> Yes, I have tried with bin/latency user space application and the system
> crashes.

latency appears to crash on ARM when launched with the default 100us
period, the system is just too busy. Do you observe the crash with a 1
ms period ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] crashing 2.6.22

[Labozzetta, Saverio]

[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]





-----Original Message-----
From: xenomai-core-bounces@domain.hid on behalf of Labozzetta, Saverio
Sent: Mon 2007-10-01 2:42 PM
To: Jan Kiszka; Gilles Chanteperdrix
Cc: xenomai-core
Subject: Re: [Xenomai-core] crashing 2.6.22
 




>>-----Original Message-----
>>From: xenomai-core-bounces@domain.hid on behalf of Jan Kiszka
>>Sent: Mon 2007-10-01 11:32 AM
>>To: Gilles Chanteperdrix
>>Cc: xenomai-core
>Subject: Re: [Xenomai-core] crashing 2.6.22
>> 
>>Gilles Chanteperdrix wrote:
>>> On 10/1/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> On 9/30/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>>>> Philippe Gerum wrote:
>>>>>>> On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> Philippe Gerum wrote:
>>>>>>>>>> On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote:
>>>>>>>> ...
>>>>>>>>>>>  And a third
>>>>>>>>>>> one only gives me "Detected illicit call from domain Xenomai" before the
>>>>>>>>>>> box reboots. :(
>>>>>>>>>> Grmff... Do you run with your smp_processor_id() instrumentation in?
>>>>>>>>> Yes, but I suspect this is just a symptom of some severe memory
>>>>>>>>> corruption that (also?) hits I-pipe data structures. I just put in some
>>>>>>>>> different instrumentation, and that warning is gone, the box just hangs
>>>>>>>>> hard at a different point. Very unfriendly.
>>>>>>>> Hah! Got some crash log by hacking a raw printk-to-uart:
>>>>>>>>
>>>>>>>> [...]
>>>>>>>> <6>Xenomai: starting RTDM services.
>>>>>>>> <6>NET: Registered protocol family 10
>>>>>>>> <6>lo: Disabled Privacy Extensions
>>>>>>>> <6>ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>>>>>> <3>I-pipe: Detected illicit call from domain 'Xenomai'
>>>>>>>> <3>        into a service reserved for domain 'Linux' and below.
>>>>>>>>        f3a6bc18 00000000 00000000 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100
>>>>>>>>        00000009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70
>>>>>>>>        c0127224 c0111df8 00000000 f3a6bd74 00000000 f3a6bd74 f3a6bc80 c012727f
>>>>>>>> Call Trace:
>>>>>>>>  [<c010520f>] show_trace_log_lvl+0x1f/0x40
>>>>>>>>  [<c01052e1>] show_stack_log_lvl+0xb1/0xe0
>>>>>>>>  [<c0105fc3>] show_stack+0x33/0x40
>>>>>>>>  [<c01479cb>] ipipe_check_context+0x7b/0x90
>>>>>>>>  [<c0127224>] __atomic_notifier_call_chain+0x24/0x60
>>>>>>>>  [<c012727f>] atomic_notifier_call_chain+0x1f/0x30
>>>>>>>>  [<c0131e02>] notify_die+0x32/0x40
>>>>>>>>  [<c0105d29>] do_invalid_op+0x59/0xa0
>>>>>>>>  [<c0111d0b>] __ipipe_handle_exception+0x7b/0x144
>>>>>>>>  [<c02dfaeb>] error_code+0x6f/0x7c
>>>>>>> Wow. Why that?
>>>>>>>
>>>>>>>>  [<c0111d13>] __ipipe_handle_exception+0x83/0x144
>>>>>>>>  [<c02dfaeb>] error_code+0x6f/0x7c
>>>>>>> And this? We should not get any exception over an IPI3 handler. I guess
>>>>>>> the double fault may be explained by this root cause.
>>>>>>>
>>>>>>>>  [<c01117df>] __ipipe_handle_irq+0x4f/0x140
>>>>>>>>  [<c0104c5e>] ipipe_ipi3+0x26/0x40
>>>>>>> Our LAPIC timer vector. Are you running full modular or statically btw?
>>>>>> Fully modular. Compiling the nucleus in makes the lock-up move to
>>>>>> another, once again invisible spot.
>>>>>
>>>>>> I nailed down the fault address in the scenario above. It's in the
>>>>>> nucleus module, at the first byte of xntimer_tick_aperiodic. Are we
>>>>>> loosing module text pages over the time? This functions must have been
>>>>>> executed before as the timer was armed while I collected the
>>>>>> /proc/modules and then triggered the crash.
>>>>> There is a pending issue about vmalloced areas, which I completely forgot:
>>>>> https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html
>>>>>
>>>> Would this explain my problems which are already visible without any
>>>> Xenomai application running (and also without unloading the modules
>>>> again, to answer Philippe's question)? Hell, I would love to find the
>>>> reason here, debugging this stuff stopped being fun a long time ago...
>>> 
>>> It would explain bugs involving a race between task creation and
>>> vmalloc/ioremap. But the bug would only happen with Xenomai tasks
>>> running,
>>
>>I don't need to start any Xenomai task to trigger the problem.
>>
>>> otherwise, the vmalloced/ioremaped area would be mapped lazily as usual.
>>
>>I guess module text pages are not mapped lazily, otherwise quite a lot 
>>of things would have fallen apart much earlier, right?
>
> AFAIK Once inserted module text pages are part of the kernel, so have
>to be reliably ready as long as the servicies offered are registred,
>is the insertion function which allocates memory, access it to write 
>the text of the module and make it part of the kernel, so is keep in 
>main memory.
>

I've been silly: the pages are directly allocated in kernel space (GFP_KERNEL),
and some of their addresses are pointed by the function offered in some
kernel tables...

BTW: sorry about the following nasty copiright abuse patch, is automatically
attached to any mail I send outside, an sorry also for the filthy email client
I use, but I've not found other ways since they put exchange on... 

>  Saverio
>
>>
>>Jan
>>
>>-- 
>>Siemens AG, Corporate Technology, CT SE 2
>>Corporate Competence Center Embedded Linux
>>




This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.

[-- Attachment #2: Type: text/html, Size: 8834 bytes --]

[Xenomai-help] rt_task crash kernel

[Patrick]

[-- Attachment #1.1: Type: text/plain, Size: 926 bytes --]

Hi,

 

I'm using Xenomai 2.3.4 with 2.6.20 kernel on an ARM PXA270 board.

The installation was executed successfully.

 

Now I'm trying to insert a small test module (source code is attached) but
the kernel crashes on rt_task_start().

I have tried the same module on another x86 machine and there is no problem.


I have tried with or without rt_task_set_periodic in aperiodic and periodic
timer mode but the result is the same.

 

Do you have an idea?

 

Regards

 

This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.

	

[-- Attachment #1.2: Type: text/html, Size: 4351 bytes --]

[-- Attachment #2: myModule_m.c --]
[-- Type: text/plain, Size: 1550 bytes --]

/*******************************************************************
 * isrtimer_m.c 
 *******************************************************************/

#include <native/task.h>
#include <native/intr.h>
#include <native/alarm.h>

#define STACK_SIZE         8192        /* Taille de la pile par défaut */
#define MS                 1000000     /* 1 ms exprimé en ns */
#define TIMER_PERIODIC     1           /* 1: timer périodique, 0: timer apériodique */

RT_TASK myTask;
RT_ALARM myAlarm;

int err; /* stockage du code d'erreur */


/* cleanup_module() */
void __exit cleanup_module (void) {

  printk("#irqtimer: cleanup\n");

  rt_task_delete(&myTask);

  printk("Bye bye!\n");
}

/* Tâche périodique */
void periodic(void *cookie) {
   while(1) {
      printk("debut 20ms\n");
      rt_timer_spin(20 * MS);
      printk("fin 20ms\n");
      rt_task_wait_period(NULL);
   }
}

/* init_module() */
int __init init_module (void) {

  printk("#module de test: starting...\n");

  
  /* Timer initialization */
  if (TIMER_PERIODIC)
    err = rt_timer_set_mode(MS);   /* periodic mode, one tick will be equal to 1 ms */ 
  else
    err = rt_timer_set_mode(TM_ONESHOT);

  if (err != 0) {
    printk("Error timer: %d\n", err);
    return -1;
  }


  /*Création de la tache*/
  rt_task_create(&myTask, "taskCharge", STACK_SIZE, 10, 0);
  //rt_task_set_periodic(&myTask,TM_NOW,50*(TIMER_PERIODIC?1:MS));
  rt_task_start(&myTask, periodic, NULL);

  return 0;
}

MODULE_LICENSE("GPL");

Re: [Xenomai-help] rt_task crash kernel

[Gilles Chanteperdrix]

On 10/2/07, Patrick <kpa_info@domain.hid> wrote:
>
>
>
>
> Hi,
>
>
>
> I'm using Xenomai 2.3.4 with 2.6.20 kernel on an ARM PXA270 board.
>
> The installation was executed successfully.
>
>
>
> Now I'm trying to insert a small test module (source code is attached) but the kernel crashes on rt_task_start().
>
> I have tried the same module on another x86 machine and there is no problem.
>
> I have tried with or without rt_task_set_periodic in aperiodic and periodic timer mode but the result is the same.
>
>
>
> Do you have an idea?

Do you observe the same behaviour with the latency test ?

-- 
                                               Gilles Chanteperdrix