[Xenomai] rtdm_task_init call freezes the system

[Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

I'm writing an SPI device driver using rtdm skin. If I call rtdm_task_init
from anywhere in the code the system freezes indefinitely with no errors
thrown.

Here is how I call the function in __init function of my module:
retval = rtdm_task_init(&heartbeat_task, "spi_transfer", xx_start_transfer,
NULL, 99, 100000000);

I'm using xenomai 2.6.1 patched with
adeos-ipipe-2.6.38.8-arm-1.18-09.patch<http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-09.patch>
Linux 2.6.38.8 and my compiler is Sourcery G++ Lite 2010q1-202

The rtdm_timer_start function works perfectly so the problem is only with
the task function.

I've been trying different kernel versions but I get the same result.

I'm attaching the .config file in case there is a setting that's causing
this issue.

Thanks in advance,

Nima
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 36797 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140103/ef5b53d0/attachment.obj>

Re: [Xenomai] rtdm_task_init call freezes the system

[Philippe Gerum]

On 01/04/2014 01:48 AM, Nima Nourozi wrote:
> I'm writing an SPI device driver using rtdm skin. If I call rtdm_task_init
> from anywhere in the code the system freezes indefinitely with no errors
> thrown.
>
> Here is how I call the function in __init function of my module:
> retval = rtdm_task_init(&heartbeat_task, "spi_transfer", xx_start_transfer,
> NULL, 99, 100000000);
>
> I'm using xenomai 2.6.1 patched with
> adeos-ipipe-2.6.38.8-arm-1.18-09.patch<http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-09.patch>
> Linux 2.6.38.8 and my compiler is Sourcery G++ Lite 2010q1-202
>
> The rtdm_timer_start function works perfectly so the problem is only with
> the task function.
>
> I've been trying different kernel versions but I get the same result.
>
> I'm attaching the .config file in case there is a setting that's causing
> this issue.
>

Check your own code in xx_start_transfer. It is likely running away, 
locking up the system. Enabling CONFIG_XENO_OPT_WATCHDOG may help.

-- 
Philippe.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/04/2014 10:06 AM, Philippe Gerum wrote:
> On 01/04/2014 01:48 AM, Nima Nourozi wrote:
>> I'm writing an SPI device driver using rtdm skin. If I call rtdm_task_init
>> from anywhere in the code the system freezes indefinitely with no errors
>> thrown.
>>
>> Here is how I call the function in __init function of my module:
>> retval = rtdm_task_init(&heartbeat_task, "spi_transfer", xx_start_transfer,
>> NULL, 99, 100000000);
>>
>> I'm using xenomai 2.6.1 patched with
>> adeos-ipipe-2.6.38.8-arm-1.18-09.patch<http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-09.patch>
>> Linux 2.6.38.8 and my compiler is Sourcery G++ Lite 2010q1-202
>>
>> The rtdm_timer_start function works perfectly so the problem is only with
>> the task function.
>>
>> I've been trying different kernel versions but I get the same result.
>>
>> I'm attaching the .config file in case there is a setting that's causing
>> this issue.
>>
> 
> Check your own code in xx_start_transfer. It is likely running away, 
> locking up the system. Enabling CONFIG_XENO_OPT_WATCHDOG may help.
> 

If it is periodic, chances are the period is too short.

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Philippe Gerum]

On 01/04/2014 07:18 PM, Gilles Chanteperdrix wrote:
> On 01/04/2014 10:06 AM, Philippe Gerum wrote:
>> On 01/04/2014 01:48 AM, Nima Nourozi wrote:
>>> I'm writing an SPI device driver using rtdm skin. If I call rtdm_task_init
>>> from anywhere in the code the system freezes indefinitely with no errors
>>> thrown.
>>>
>>> Here is how I call the function in __init function of my module:
>>> retval = rtdm_task_init(&heartbeat_task, "spi_transfer", xx_start_transfer,
>>> NULL, 99, 100000000);
>>>
>>> I'm using xenomai 2.6.1 patched with
>>> adeos-ipipe-2.6.38.8-arm-1.18-09.patch<http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-09.patch>
>>> Linux 2.6.38.8 and my compiler is Sourcery G++ Lite 2010q1-202
>>>
>>> The rtdm_timer_start function works perfectly so the problem is only with
>>> the task function.
>>>
>>> I've been trying different kernel versions but I get the same result.
>>>
>>> I'm attaching the .config file in case there is a setting that's causing
>>> this issue.
>>>
>>
>> Check your own code in xx_start_transfer. It is likely running away,
>> locking up the system. Enabling CONFIG_XENO_OPT_WATCHDOG may help.
>>
>
> If it is periodic, chances are the period is too short.
>

The period is set to 100 ms, should be ok. Provided rtdm_wait_period() 
is properly called from that task, that is.

-- 
Philippe.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

Here is the task function. But I'm not seeing the printout.

void xx_start_transfer(void *arg) {
  rtdm_wait_period();
  rtdm_printk("hello world\n");
}


On Sat, Jan 4, 2014 at 11:27 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 01/04/2014 07:18 PM, Gilles Chanteperdrix wrote:
>
>> On 01/04/2014 10:06 AM, Philippe Gerum wrote:
>>
>>> On 01/04/2014 01:48 AM, Nima Nourozi wrote:
>>>
>>>> I'm writing an SPI device driver using rtdm skin. If I call
>>>> rtdm_task_init
>>>> from anywhere in the code the system freezes indefinitely with no errors
>>>> thrown.
>>>>
>>>> Here is how I call the function in __init function of my module:
>>>> retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
>>>> xx_start_transfer,
>>>> NULL, 99, 100000000);
>>>>
>>>> I'm using xenomai 2.6.1 patched with
>>>> adeos-ipipe-2.6.38.8-arm-1.18-09.patch<http://download.gna.
>>>> org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-09.patch>
>>>> Linux 2.6.38.8 and my compiler is Sourcery G++ Lite 2010q1-202
>>>>
>>>> The rtdm_timer_start function works perfectly so the problem is only
>>>> with
>>>> the task function.
>>>>
>>>> I've been trying different kernel versions but I get the same result.
>>>>
>>>> I'm attaching the .config file in case there is a setting that's causing
>>>> this issue.
>>>>
>>>>
>>> Check your own code in xx_start_transfer. It is likely running away,
>>> locking up the system. Enabling CONFIG_XENO_OPT_WATCHDOG may help.
>>>
>>>
>> If it is periodic, chances are the period is too short.
>>
>>
> The period is set to 100 ms, should be ok. Provided rtdm_wait_period() is
> properly called from that task, that is.
>
> --
> Philippe.
>

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/04/2014 09:29 PM, Nima Nourozi wrote:
> Here is the task function. But I'm not seeing the printout.
> 
> void xx_start_transfer(void *arg) {
>   rtdm_wait_period();
>   rtdm_printk("hello world\n");
> }

Two things to try:
- see if:
latency -t 1 -p 100000
has the same issue?
- xenomai 2.6.3 instead of 2.6.1


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Sat, Jan 4, 2014 at 1:24 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/04/2014 09:29 PM, Nima Nourozi wrote:
> > Here is the task function. But I'm not seeing the printout.
> >
> > void xx_start_transfer(void *arg) {
> >   rtdm_wait_period();
> >   rtdm_printk("hello world\n");
> > }
>
> Two things to try:
> - see if:
> latency -t 1 -p 100000
> has the same issue?
> - xenomai 2.6.3 instead of 2.6.1
>
>
> --
>                                                                 Gilles.
>

Will do when I get back to the office on Monday. I don't have the hardware
at the house.

I noticed xenomai 2.6.3 does not contain the adeos patch for linux
2.6.38.8. Should I just put the patch I downloaded from adeos in the patch
folder and patch the vanilla kernel that way?

Re: [Xenomai] rtdm_task_init call freezes the system

[Philippe Gerum]

On 01/04/2014 09:29 PM, Nima Nourozi wrote:
> Here is the task function. But I'm not seeing the printout.
>
> void xx_start_transfer(void *arg) {
>    rtdm_wait_period();

What about checking the return code of rtdm_wait_period()? If something 
goes wrong there, you do want to know, instead of entering a tight 
runaway loop.

-- 
Philippe.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/04/2014 10:31 PM, Nima Nourozi wrote:
> On Sat, Jan 4, 2014 at 1:24 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>> Here is the task function. But I'm not seeing the printout.
>>>
>>> void xx_start_transfer(void *arg) {
>>>   rtdm_wait_period();
>>>   rtdm_printk("hello world\n");
>>> }
>>
>> Two things to try:
>> - see if:
>> latency -t 1 -p 100000
>> has the same issue?
>> - xenomai 2.6.3 instead of 2.6.1
>>
>>
>> --
>>                                                                 Gilles.
>>
> 
> Will do when I get back to the office on Monday. I don't have the hardware
> at the house.
> 
> I noticed xenomai 2.6.3 does not contain the adeos patch for linux
> 2.6.38.8. Should I just put the patch I downloaded from adeos in the patch
> folder and patch the vanilla kernel that way?
> 

Yes, it should work.

Also, the bug you mention reminds me of an old issue, which I am afraid
got forgotten.

Could you try disabling CONFIG_HIGH_RES_TIMERS ?

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>
>> Here is the task function. But I'm not seeing the printout.
>>
>> void xx_start_transfer(void *arg) {
>>    rtdm_wait_period();
>>
>
> What about checking the return code of rtdm_wait_period()? If something
> goes wrong there, you do want to know, instead of entering a tight runaway
> loop.
>
> --
> Philippe.
>

I can't print anything since the system freezes so I don't know how I can
check return value? Also, what loop are you referring to I don't have a
loop just a print statement.

Nima

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Sat, Jan 4, 2014 at 3:01 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/04/2014 10:31 PM, Nima Nourozi wrote:
> > On Sat, Jan 4, 2014 at 1:24 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> On 01/04/2014 09:29 PM, Nima Nourozi wrote:
> >>> Here is the task function. But I'm not seeing the printout.
> >>>
> >>> void xx_start_transfer(void *arg) {
> >>>   rtdm_wait_period();
> >>>   rtdm_printk("hello world\n");
> >>> }
> >>
> >> Two things to try:
> >> - see if:
> >> latency -t 1 -p 100000
> >> has the same issue?
> >> - xenomai 2.6.3 instead of 2.6.1
> >>
> >>
> >> --
> >>                                                                 Gilles.
> >>
> >
> > Will do when I get back to the office on Monday. I don't have the
> hardware
> > at the house.
> >
> > I noticed xenomai 2.6.3 does not contain the adeos patch for linux
> > 2.6.38.8. Should I just put the patch I downloaded from adeos in the
> patch
> > folder and patch the vanilla kernel that way?
> >
>
> Yes, it should work.
>
> Also, the bug you mention reminds me of an old issue, which I am afraid
> got forgotten.
>
> Could you try disabling CONFIG_HIGH_RES_TIMERS ?
>
> --
>                                                                 Gilles.
>

OK I'll try 2.6.3 on Monday and I'll disable CONFIG_HIGH_RES_TIMERS which
is currently enabled.

I'm curious to hear more about the bug you mentioned.

Nima

Re: [Xenomai] rtdm_task_init call freezes the system

[Philippe Gerum]

On 01/05/2014 01:25 AM, Nima Nourozi wrote:
> On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
>
>     On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>
>         Here is the task function. But I'm not seeing the printout.
>
>         void xx_start_transfer(void *arg) {
>             rtdm_wait_period();
>
>
>     What about checking the return code of rtdm_wait_period()? If
>     something goes wrong there, you do want to know, instead of entering
>     a tight runaway loop.
>
>     --
>     Philippe.
>
>
> I can't print anything since the system freezes so I don't know how I
> can check return value? Also, what loop are you referring to I don't
> have a loop just a print statement.

It does not make sense to have a single wait statement in a periodic 
task, you should have a loop. Or you don't have periodic task. So your 
task should implement a loop.

To force a direct output through the serial console port, you may want 
to try enabling DEBUG_LL and IPIPE_DEBUG, then call 
__ipipe_serial_debug(), instead of printk. Do not use this in regular 
code, this is for debugging purpose only, in mostly hopeless situations 
where using buffered console output is not an option.

Preventing the thread to exit by suspending it indefinitely before the 
routine returns would also help debugging. Calling rtdm_task_sleep(0) 
should do this.

-- 
Philippe.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/05/2014 01:31 AM, Nima Nourozi wrote:
> On Sat, Jan 4, 2014 at 3:01 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/04/2014 10:31 PM, Nima Nourozi wrote:
>>> On Sat, Jan 4, 2014 at 1:24 PM, Gilles Chanteperdrix <
>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>
>>>> On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>>>> Here is the task function. But I'm not seeing the printout.
>>>>>
>>>>> void xx_start_transfer(void *arg) {
>>>>>   rtdm_wait_period();
>>>>>   rtdm_printk("hello world\n");
>>>>> }
>>>>
>>>> Two things to try:
>>>> - see if:
>>>> latency -t 1 -p 100000
>>>> has the same issue?
>>>> - xenomai 2.6.3 instead of 2.6.1
>>>>
>>>>
>>>> --
>>>>                                                                 Gilles.
>>>>
>>>
>>> Will do when I get back to the office on Monday. I don't have the
>> hardware
>>> at the house.
>>>
>>> I noticed xenomai 2.6.3 does not contain the adeos patch for linux
>>> 2.6.38.8. Should I just put the patch I downloaded from adeos in the
>> patch
>>> folder and patch the vanilla kernel that way?
>>>
>>
>> Yes, it should work.
>>
>> Also, the bug you mention reminds me of an old issue, which I am afraid
>> got forgotten.
>>
>> Could you try disabling CONFIG_HIGH_RES_TIMERS ?
>>
>> --
>>                                                                 Gilles.
>>
> 
> OK I'll try 2.6.3 on Monday and I'll disable CONFIG_HIGH_RES_TIMERS which
> is currently enabled.
> 
> I'm curious to hear more about the bug you mentioned.

The AT91 clocksource is based on a 16 bits counter which wraps fast. To
get the clocksource working, we need to "update" the clocksource at
least once for every wrap. The solution found to do this which has the
lowest overhead is to do this in Linux timer interrupt. But with
CONFIG_HIGH_RES_TIMERS (and a real one-shot timer, which not all the
AT91 have), we have no guarantee that the Linux timer interrupt will
tick often enough.

I am not sure this is the issue you see, since you mentioned that you
could start a timer.


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/05/2014 01:02 PM, Philippe Gerum wrote:
> On 01/05/2014 01:25 AM, Nima Nourozi wrote:
>> On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org
>> <mailto:rpm@xenomai.org>> wrote:
>>
>>     On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>
>>         Here is the task function. But I'm not seeing the printout.
>>
>>         void xx_start_transfer(void *arg) {
>>             rtdm_wait_period();
>>
>>
>>     What about checking the return code of rtdm_wait_period()? If
>>     something goes wrong there, you do want to know, instead of entering
>>     a tight runaway loop.
>>
>>     --
>>     Philippe.
>>
>>
>> I can't print anything since the system freezes so I don't know how I
>> can check return value? Also, what loop are you referring to I don't
>> have a loop just a print statement.
> 
> It does not make sense to have a single wait statement in a periodic 
> task, you should have a loop. Or you don't have periodic task. So your 
> task should implement a loop.
> 
> To force a direct output through the serial console port, you may want 
> to try enabling DEBUG_LL and IPIPE_DEBUG, then call 
> __ipipe_serial_debug(), instead of printk. Do not use this in regular 
> code, this is for debugging purpose only, in mostly hopeless situations 
> where using buffered console output is not an option.

I do not think 2.6.38 has __ipipe_serial_debug, it as printascii though.


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Sun, Jan 5, 2014 at 4:02 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 01/05/2014 01:25 AM, Nima Nourozi wrote:
>
>> On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org
>> <mailto:rpm@xenomai.org>> wrote:
>>
>>     On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>
>>         Here is the task function. But I'm not seeing the printout.
>>
>>         void xx_start_transfer(void *arg) {
>>             rtdm_wait_period();
>>
>>
>>     What about checking the return code of rtdm_wait_period()? If
>>     something goes wrong there, you do want to know, instead of entering
>>     a tight runaway loop.
>>
>>     --
>>     Philippe.
>>
>>
>> I can't print anything since the system freezes so I don't know how I
>> can check return value? Also, what loop are you referring to I don't
>> have a loop just a print statement.
>>
>
> It does not make sense to have a single wait statement in a periodic task,
> you should have a loop. Or you don't have periodic task. So your task
> should implement a loop.
>
> To force a direct output through the serial console port, you may want to
> try enabling DEBUG_LL and IPIPE_DEBUG, then call __ipipe_serial_debug(),
> instead of printk. Do not use this in regular code, this is for debugging
> purpose only, in mostly hopeless situations where using buffered console
> output is not an option.
>
> Preventing the thread to exit by suspending it indefinitely before the
> routine returns would also help debugging. Calling rtdm_task_sleep(0)
> should do this.
>
> --
> Philippe.
>

Initially I set the periodicity in the init_task to zero to get a one-shot
task to transfer the spi data. But that was freezing the system as well so
I changed my code to mimic what the demo code was doing, hence a periodic
task but without a loop.

I'll add the loop on Monday to see if it makes a difference.

Re: [Xenomai] rtdm_task_init call freezes the system

[Philippe Gerum]

On 01/05/2014 08:28 PM, Gilles Chanteperdrix wrote:
> On 01/05/2014 01:02 PM, Philippe Gerum wrote:
>> On 01/05/2014 01:25 AM, Nima Nourozi wrote:
>>> On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org
>>> <mailto:rpm@xenomai.org>> wrote:
>>>
>>>      On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>>
>>>          Here is the task function. But I'm not seeing the printout.
>>>
>>>          void xx_start_transfer(void *arg) {
>>>              rtdm_wait_period();
>>>
>>>
>>>      What about checking the return code of rtdm_wait_period()? If
>>>      something goes wrong there, you do want to know, instead of entering
>>>      a tight runaway loop.
>>>
>>>      --
>>>      Philippe.
>>>
>>>
>>> I can't print anything since the system freezes so I don't know how I
>>> can check return value? Also, what loop are you referring to I don't
>>> have a loop just a print statement.
>>
>> It does not make sense to have a single wait statement in a periodic
>> task, you should have a loop. Or you don't have periodic task. So your
>> task should implement a loop.
>>
>> To force a direct output through the serial console port, you may want
>> to try enabling DEBUG_LL and IPIPE_DEBUG, then call
>> __ipipe_serial_debug(), instead of printk. Do not use this in regular
>> code, this is for debugging purpose only, in mostly hopeless situations
>> where using buffered console output is not an option.
>
> I do not think 2.6.38 has __ipipe_serial_debug,

It does. printascii() alone would not prevent output races, so it's 
better to use __ipipe_serial_debug() for this.

  it as printascii though.
>
>

-- 
Philippe.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Sun, Jan 5, 2014 at 11:58 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 01/05/2014 08:28 PM, Gilles Chanteperdrix wrote:
>
>> On 01/05/2014 01:02 PM, Philippe Gerum wrote:
>>
>>> On 01/05/2014 01:25 AM, Nima Nourozi wrote:
>>>
>>>> On Sat, Jan 4, 2014 at 2:57 PM, Philippe Gerum <rpm@xenomai.org
>>>> <mailto:rpm@xenomai.org>> wrote:
>>>>
>>>>      On 01/04/2014 09:29 PM, Nima Nourozi wrote:
>>>>
>>>>          Here is the task function. But I'm not seeing the printout.
>>>>
>>>>          void xx_start_transfer(void *arg) {
>>>>              rtdm_wait_period();
>>>>
>>>>
>>>>      What about checking the return code of rtdm_wait_period()? If
>>>>      something goes wrong there, you do want to know, instead of
>>>> entering
>>>>      a tight runaway loop.
>>>>
>>>>      --
>>>>      Philippe.
>>>>
>>>>
>>>> I can't print anything since the system freezes so I don't know how I
>>>> can check return value? Also, what loop are you referring to I don't
>>>> have a loop just a print statement.
>>>>
>>>
>>> It does not make sense to have a single wait statement in a periodic
>>> task, you should have a loop. Or you don't have periodic task. So your
>>> task should implement a loop.
>>>
>>> To force a direct output through the serial console port, you may want
>>> to try enabling DEBUG_LL and IPIPE_DEBUG, then call
>>> __ipipe_serial_debug(), instead of printk. Do not use this in regular
>>> code, this is for debugging purpose only, in mostly hopeless situations
>>> where using buffered console output is not an option.
>>>
>>
>> I do not think 2.6.38 has __ipipe_serial_debug,
>>
>
> It does. printascii() alone would not prevent output races, so it's better
> to use __ipipe_serial_debug() for this.
>
>
>  it as printascii though.
>
>>
>>
>>
> --
> Philippe.
>


OK I patched xenomai 2.6.3 and enabled DEBUG_LL,  IPIPE_DEBUG and
disabled CONFIG_HIGH_RES_TIMERS.
I've attached the latest .config for reference.

Here is the task initialization code:

*rtdm_printk("kicking of tasklet...\n");*
* retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
* __ipipe_serial_debug("*******return value = %d\n", retval);*
* if(retval)*
* {*
* __ipipe_serial_debug("error initializing task: %i\n", retval);*
* }*

Here is the task function:

void xx_start_transfer(void *arg)
{

int ret;

while (1) {
ret = rtdm_task_wait_period();
__ipipe_serial_debug("*******return value = %d\n", ret);
gpio_set_value(LED, 1);
rtdm_task_sleep(0);
}
}

I'm not seeing any output from any of the __ipipe_serial_debug(), however I'm
seeing the following kernel error (full console output attached):

------------[ cut here ]------------

WARNING: at kernel/sched.c:3826 add_preempt_count+0x68/0x104()

Modules linked in:

Backtrace:

[<c002ea10>] (dump_backtrace+0x0/0x110) from [<c02d7b84>]
(dump_stack+0x18/0x1c)
 r6:c035110f r5:00000ef2 r4:00000000

[<c02d7b6c>] (dump_stack+0x0/0x1c) from [<c003fc30>]
(warn_slowpath_common+0x54/
0x6c)

[<c003fbdc>] (warn_slowpath_common+0x0/0x6c) from [<c003fc6c>]
(warn_slowpath_nu
ll+0x24/0x28)

 r8:c03554b1 r7:00000001 r6:c03a3830 r5:c0543a60 r4:00000001

[<c003fc48>] (warn_slowpath_null+0x0/0x28) from [<c0038824>]
(add_preempt_count+
0x68/0x104)

[<c00387bc>] (add_preempt_count+0x0/0x104) from [<c0040998>]
(vprintk+0x54/0x400
)

 r4:00000000

[<c0040944>] (vprintk+0x0/0x400) from [<c02d7e04>] (printk+0xfc/0x1a8)

[<c02d7d08>] (printk+0x0/0x1a8) from [<c0075c80>]
(ipipe_check_context+0xa0/0xd0
)

 r3:00001c70 r2:c03517a4 r1:c0355d9b r0:c03554b1

 r8:00000000 r7:eef84a10 r6:c03a3830 r5:c0543a60 r4:c0541d40

[<c0075be0>] (ipipe_check_context+0x0/0xd0) from [<c00387d4>]
(add_preempt_count
+0x18/0x104)

 r6:c3900050 r5:c02453cc r4:00000001

[<c00387bc>] (add_preempt_count+0x0/0x104) from [<c0025130>]
(do_undefinstr+0x90
/0x1c8)

 r4:c3901548

[<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>]
(__und_svc+0x54/0x80)

Nima
-------------- next part --------------
Starting kernel ...                                                             
                                                                                
Uncompressing Linux... done, booting the kernel.                                
Linux version 2.6.38.8 (nima@nima-ThinkPad-W530) (gcc version 4.4.1 (Sourcery G+
+ Lite 2010q1-202) ) #12 PREEMPT Mon Jan 6 10:59:01 PST 2014                    
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177                   
CPU: VIVT data cache, VIVT instruction cache                                    
Machine: Valhalla Base Station 32                                               
Memory policy: ECC disabled, Data cache writeback                               
Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz                             
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256      
Kernel command line: mem=64M console=ttyS0,115200 root=/dev/mtdblock2 rw rootfst
ype=jffs2 mtdparts=atmel_nand:1M(bootloader),2M(kernel),-(rootfs)               
PID hash table entries: 256 (order: -2, 1024 bytes)                             
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)                   
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)                    
Memory: 64MB = 64MB total                                                       
Memory: 59388k/59388k available, 6148k reserved, 0K highmem                     
Virtual kernel memory layout:                                                   
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)                               
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)                               
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)                               
    vmalloc : 0xc4800000 - 0xfee00000   ( 934 MB)                               
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)                               
    modules : 0xbf000000 - 0xc0000000   (  16 MB)                               
      .init : 0xc0008000 - 0xc0025000   ( 116 kB)                               
      .text : 0xc0025000 - 0xc0395000   (3520 kB)                               
      .data : 0xc0396000 - 0xc0536560   (1666 kB)                               
NR_IRQS:192                                                                     
AT91: 96 gpio irqs in 3 banks                                                   
AT91 I-pipe timer: div: 32, freq: 3.104000 MHz, wrap: 21.113402 ms              
I-pipe, 3.104 MHz clocksource                                                   
I-pipe 1.18-09: pipeline enabled.                                               
Console: colour dummy device 80x30                                              
console [ttyS0] enabled                                                         
Calibrating delay loop... 93.24 BogoMIPS (lpj=45696)                            
pid_max: default: 32768 minimum: 301                                            
Mount-cache hash table entries: 512                                             
CPU: Testing write buffer coherency: ok                                         
NET: Registered protocol family 16                                              
bio: create slab <bio-0> at 0                                                   
Switching to clocksource ipipe_tsc                                              
NET: Registered protocol family 2                                               
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)                  
TCP established hash table entries: 2048 (order: 2, 16384 bytes)                
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)                        
TCP: Hash tables configured (established 2048 bind 2048)                        
TCP reno registered                                                             
UDP hash table entries: 256 (order: 0, 4096 bytes)                              
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)                         
NET: Registered protocol family 1                                               
RPC: Registered udp transport module.                                           
RPC: Registered tcp transport module.                                           
RPC: Registered tcp NFSv4.1 backchannel transport module.                       
I-pipe: Domain Xenomai registered.                                              
Xenomai: hal/arm started.                                                       
Xenomai: scheduling class idle registered.                                      
Xenomai: scheduling class rt registered.                                        
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.                     
Xenomai: debug mode enabled.                                                    
Xenomai: starting native API services.                                          
Xenomai: starting POSIX services.                                               
Xenomai: starting RTDM services.                                                
JFFS2 version 2.2. (NAND) ?© 2001-2006 Red Hat, Inc.                            
ROMFS MTD (C) 2007 Red Hat, Inc.                                                
msgmni has been set to 115                                                      
NET: Registered protocol family 38                                              
io scheduler noop registered (default)                                          
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL             
brd: module loaded                                                              
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bi
t)                                                                              
Scanning device for bad blocks                                                  
Bad eraseblock 182 at 0x0000016c0000                                            
Bad eraseblock 788 at 0x000006280000                                            
Bad eraseblock 1116 at 0x000008b80000                                           
Bad eraseblock 1117 at 0x000008ba0000                                           
Bad eraseblock 1206 at 0x0000096c0000                                           
Bad eraseblock 1422 at 0x00000b1c0000                                           
Bad eraseblock 1678 at 0x00000d1c0000                                           
Bad eraseblock 1679 at 0x00000d1e0000                                           
Bad eraseblock 1812 at 0x00000e280000                                           
Bad eraseblock 1952 at 0x00000f400000                                           
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":                          
0x000000000000-0x000000100000 : "U-boot"                                        
0x000000100000-0x000000300000 : "Kernel"                                        
0x000000300000-0x000010000000 : "File system"                                   
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12)              
kicking of tasklet...                                                           
------------[ cut here ]------------                                            
WARNING: at kernel/sched.c:3826 add_preempt_count+0x68/0x104()                  
Modules linked in:                                                              
Backtrace:                                                                      
[<c002ea10>] (dump_backtrace+0x0/0x110) from [<c02d7b84>] (dump_stack+0x18/0x1c)
 r6:c035110f r5:00000ef2 r4:00000000                                            
[<c02d7b6c>] (dump_stack+0x0/0x1c) from [<c003fc30>] (warn_slowpath_common+0x54/
0x6c)                                                                           
[<c003fbdc>] (warn_slowpath_common+0x0/0x6c) from [<c003fc6c>] (warn_slowpath_nu
ll+0x24/0x28)                                                                   
 r8:c03554b1 r7:00000001 r6:c03a3830 r5:c0543a60 r4:00000001                    
[<c003fc48>] (warn_slowpath_null+0x0/0x28) from [<c0038824>] (add_preempt_count+
0x68/0x104)                                                                     
[<c00387bc>] (add_preempt_count+0x0/0x104) from [<c0040998>] (vprintk+0x54/0x400
)                                                                               
 r4:00000000                                                                    
[<c0040944>] (vprintk+0x0/0x400) from [<c02d7e04>] (printk+0xfc/0x1a8)          
[<c02d7d08>] (printk+0x0/0x1a8) from [<c0075c80>] (ipipe_check_context+0xa0/0xd0
)                                                                               
 r3:00001c70 r2:c03517a4 r1:c0355d9b r0:c03554b1                                
 r8:00000000 r7:eef84a10 r6:c03a3830 r5:c0543a60 r4:c0541d40                    
[<c0075be0>] (ipipe_check_context+0x0/0xd0) from [<c00387d4>] (add_preempt_count
+0x18/0x104)                                                                    
 r6:c3900050 r5:c02453cc r4:00000001                                            
[<c00387bc>] (add_preempt_count+0x0/0x104) from [<c0025130>] (do_undefinstr+0x90
/0x1c8)                                                                         
 r4:c3901548                                                                    
[<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>] (__und_svc+0x54/0x80)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 37121 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140106/1e5d5e91/attachment.obj>

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> [<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>]
> (__und_svc+0x54/0x80)

What is interesting is what triggers this __und_svc. Will check if I can 
reproduce this bug on at91sam9263. Could you try and disable CONFIG_KGDB 
in the mean-time?

Regards.

-- 
					    Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Mon, Jan 6, 2014 at 12:00 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
>
>> [<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>]
>> (__und_svc+0x54/0x80)
>>
>
> What is interesting is what triggers this __und_svc. Will check if I can
> reproduce this bug on at91sam9263. Could you try and disable CONFIG_KGDB in
> the mean-time?
>
> Regards.
>
> --
>                                             Gilles.
>

Thanks for the quick reply Gilles. I can verify that CONFIG_KGDB was never
enabled.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 10:25 PM, Nima Nourozi wrote:
> On Mon, Jan 6, 2014 at 12:00 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
>>
>>> [<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>]
>>> (__und_svc+0x54/0x80)
>>>
>>
>> What is interesting is what triggers this __und_svc. Will check if I can
>> reproduce this bug on at91sam9263. Could you try and disable CONFIG_KGDB in
>> the mean-time?
>>
>> Regards.
>>
>> --
>>                                             Gilles.
>>
> 
> Thanks for the quick reply Gilles. I can verify that CONFIG_KGDB was never
> enabled.
> 
It is not enabled. Sorry, I did not read your configuration correctly.

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Mon, Jan 6, 2014 at 1:25 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 10:25 PM, Nima Nourozi wrote:
> > On Mon, Jan 6, 2014 at 12:00 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> >>
> >>> [<c00250a0>] (do_undefinstr+0x0/0x1c8) from [<c002abd4>]
> >>> (__und_svc+0x54/0x80)
> >>>
> >>
> >> What is interesting is what triggers this __und_svc. Will check if I can
> >> reproduce this bug on at91sam9263. Could you try and disable
> CONFIG_KGDB in
> >> the mean-time?
> >>
> >> Regards.
> >>
> >> --
> >>                                             Gilles.
> >>
> >
> > Thanks for the quick reply Gilles. I can verify that CONFIG_KGDB was
> never
> > enabled.
> >
> It is not enabled. Sorry, I did not read your configuration correctly.
>
> --
>                                                                 Gilles.
>

I don't know if this is important but I decided to
disable CONFIG_DEBUG_PREEMPT and here is the new error trace:

I-pipe: Detected illicit call from domain 'Xenomai'

<3>        into a service reserved for domain 'Linux' and below.

Backtrace:

[<c002eb54>] (dump_backtrace+0x0/0x110) from [<c02f29f8>]
(dump_stack+0x18/0x1c)
 r6:c03bd830 r5:c055da40 r4:c055bd20

[<c02f29e0>] (dump_stack+0x0/0x1c) from [<c0079d54>]
(ipipe_check_context+0xb0/0
xd0)

[<c0079ca4>] (ipipe_check_context+0x0/0xd0) from [<c002512c>]
(do_undefinstr+0x8
c/0x1f0)

 r6:c3900050 r5:c0259b10 r4:c3901548

[<c00250a0>] (do_undefinstr+0x0/0x1f0) from [<c002ac74>]
(__und_svc+0x54/0x80)

Nima

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 10:40 PM, Nima Nourozi wrote:
> [<c00250a0>] (do_undefinstr+0x0/0x1f0) from [<c002ac74>]
> (__und_svc+0x54/0x80)

The problem is do_undefinstr, which usually indicates a bug whether
intentional (using the BUG macro) or not. The rest are false positive
due to the debug checks happening during the handling of this bug.

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> Here is the task initialization code:
> 
> *rtdm_printk("kicking of tasklet...\n");*
> * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
> xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
> * __ipipe_serial_debug("*******return value = %d\n", retval);*
> * if(retval)*
> * {*
> * __ipipe_serial_debug("error initializing task: %i\n", retval);*
> * }*
> 
> Here is the task function:
> 
> void xx_start_transfer(void *arg)
> {
> 
> int ret;
> 
> while (1) {
> ret = rtdm_task_wait_period();
> __ipipe_serial_debug("*******return value = %d\n", ret);
> gpio_set_value(LED, 1);
> rtdm_task_sleep(0);
> }
> }

I can not reproduce your problem, it works fine here. Could you post the
full code of a simplified driver which triggers the problem ?


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Mon, Jan 6, 2014 at 1:45 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> > Here is the task initialization code:
> >
> > *rtdm_printk("kicking of tasklet...\n");*
> > * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
> > xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
> > * __ipipe_serial_debug("*******return value = %d\n", retval);*
> > * if(retval)*
> > * {*
> > * __ipipe_serial_debug("error initializing task: %i\n", retval);*
> > * }*
> >
> > Here is the task function:
> >
> > void xx_start_transfer(void *arg)
> > {
> >
> > int ret;
> >
> > while (1) {
> > ret = rtdm_task_wait_period();
> > __ipipe_serial_debug("*******return value = %d\n", ret);
> > gpio_set_value(LED, 1);
> > rtdm_task_sleep(0);
> > }
> > }
>
> I can not reproduce your problem, it works fine here. Could you post the
> full code of a simplified driver which triggers the problem ?
>
>
> --
>                                                                 Gilles.
>

Sure, please find it attached. It's just the standard atmel_spi.c with
task_init command added in atmel_spi_probe() function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atmel_spi.c
Type: text/x-csrc
Size: 31247 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140106/780270dd/attachment.c>

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 10:52 PM, Nima Nourozi wrote:
> On Mon, Jan 6, 2014 at 1:45 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
>>> Here is the task initialization code:
>>>
>>> *rtdm_printk("kicking of tasklet...\n");*
>>> * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
>>> xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
>>> * __ipipe_serial_debug("*******return value = %d\n", retval);*
>>> * if(retval)*
>>> * {*
>>> * __ipipe_serial_debug("error initializing task: %i\n", retval);*
>>> * }*
>>>
>>> Here is the task function:
>>>
>>> void xx_start_transfer(void *arg)
>>> {
>>>
>>> int ret;
>>>
>>> while (1) {
>>> ret = rtdm_task_wait_period();
>>> __ipipe_serial_debug("*******return value = %d\n", ret);
>>> gpio_set_value(LED, 1);
>>> rtdm_task_sleep(0);
>>> }
>>> }
>>
>> I can not reproduce your problem, it works fine here. Could you post the
>> full code of a simplified driver which triggers the problem ?
>>
>>
>> --
>>                                                                 Gilles.
>>
> 
> Sure, please find it attached. It's just the standard atmel_spi.c with
> task_init command added in atmel_spi_probe() function.
> 
Whatever happened to "simplified"? Please try to reduce your code to the
minimum code which triggers the bug. By doing so, you may even find the
problem yourself.

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 10:54 PM, Gilles Chanteperdrix wrote:
> On 01/06/2014 10:52 PM, Nima Nourozi wrote:
>> On Mon, Jan 6, 2014 at 1:45 PM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
>>>> Here is the task initialization code:
>>>>
>>>> *rtdm_printk("kicking of tasklet...\n");*
>>>> * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
>>>> xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
>>>> * __ipipe_serial_debug("*******return value = %d\n", retval);*
>>>> * if(retval)*
>>>> * {*
>>>> * __ipipe_serial_debug("error initializing task: %i\n", retval);*
>>>> * }*
>>>>
>>>> Here is the task function:
>>>>
>>>> void xx_start_transfer(void *arg)
>>>> {
>>>>
>>>> int ret;
>>>>
>>>> while (1) {
>>>> ret = rtdm_task_wait_period();
>>>> __ipipe_serial_debug("*******return value = %d\n", ret);
>>>> gpio_set_value(LED, 1);
>>>> rtdm_task_sleep(0);
>>>> }
>>>> }
>>>
>>> I can not reproduce your problem, it works fine here. Could you post the
>>> full code of a simplified driver which triggers the problem ?
>>>
>>>
>>> --
>>>                                                                 Gilles.
>>>
>>
>> Sure, please find it attached. It's just the standard atmel_spi.c with
>> task_init command added in atmel_spi_probe() function.
>>
> Whatever happened to "simplified"? Please try to reduce your code to the
> minimum code which triggers the bug. By doing so, you may even find the
> problem yourself.
> 
For instance, following your bug report, I wrote the following module:

#include <rtdm/rtdm_driver.h>

static rtdm_task_t t;

void xx_start_transfer(void *arg)
{
	rtdm_task_wait_period();
	rtdm_printk("!!!!!!!!!!!tick!\n");
}

int init(void)
{
	rtdm_task_init(&t, "spi_transfer", xx_start_transfer, NULL, 99, 100000000);
	return 0;
}

module_init(init);
MODULE_LICENSE("GPL");

Which works here. As I said, you can confirm whether rtdm_task_init 
works for your configuration by launching latency -t 1 -p 100000

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Mon, Jan 6, 2014 at 1:54 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 10:52 PM, Nima Nourozi wrote:
> > On Mon, Jan 6, 2014 at 1:45 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> >>> Here is the task initialization code:
> >>>
> >>> *rtdm_printk("kicking of tasklet...\n");*
> >>> * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
> >>> xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
> >>> * __ipipe_serial_debug("*******return value = %d\n", retval);*
> >>> * if(retval)*
> >>> * {*
> >>> * __ipipe_serial_debug("error initializing task: %i\n", retval);*
> >>> * }*
> >>>
> >>> Here is the task function:
> >>>
> >>> void xx_start_transfer(void *arg)
> >>> {
> >>>
> >>> int ret;
> >>>
> >>> while (1) {
> >>> ret = rtdm_task_wait_period();
> >>> __ipipe_serial_debug("*******return value = %d\n", ret);
> >>> gpio_set_value(LED, 1);
> >>> rtdm_task_sleep(0);
> >>> }
> >>> }
> >>
> >> I can not reproduce your problem, it works fine here. Could you post the
> >> full code of a simplified driver which triggers the problem ?
> >>
> >>
> >> --
> >>                                                                 Gilles.
> >>
> >
> > Sure, please find it attached. It's just the standard atmel_spi.c with
> > task_init command added in atmel_spi_probe() function.
> >
> Whatever happened to "simplified"? Please try to reduce your code to the
> minimum code which triggers the bug. By doing so, you may even find the
> problem yourself.
>
> --
>                                                                 Gilles.
>

Sorry about that. I thought you wanted the full code. Let me refactor it
and test and see if it does the same thing with most of the code removed.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

I'm not seeing the latency command on my board. Is it part of xenomai? I'm
using buildroot for my filesystem.


On Mon, Jan 6, 2014 at 2:11 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 10:54 PM, Gilles Chanteperdrix wrote:
> > On 01/06/2014 10:52 PM, Nima Nourozi wrote:
> >> On Mon, Jan 6, 2014 at 1:45 PM, Gilles Chanteperdrix <
> >> gilles.chanteperdrix@xenomai.org> wrote:
> >>
> >>> On 01/06/2014 08:10 PM, Nima Nourozi wrote:
> >>>> Here is the task initialization code:
> >>>>
> >>>> *rtdm_printk("kicking of tasklet...\n");*
> >>>> * retval = rtdm_task_init(&heartbeat_task, "spi_transfer",
> >>>> xx_start_transfer, NULL, 99, 100000000 /* 100 ms */);*
> >>>> * __ipipe_serial_debug("*******return value = %d\n", retval);*
> >>>> * if(retval)*
> >>>> * {*
> >>>> * __ipipe_serial_debug("error initializing task: %i\n", retval);*
> >>>> * }*
> >>>>
> >>>> Here is the task function:
> >>>>
> >>>> void xx_start_transfer(void *arg)
> >>>> {
> >>>>
> >>>> int ret;
> >>>>
> >>>> while (1) {
> >>>> ret = rtdm_task_wait_period();
> >>>> __ipipe_serial_debug("*******return value = %d\n", ret);
> >>>> gpio_set_value(LED, 1);
> >>>> rtdm_task_sleep(0);
> >>>> }
> >>>> }
> >>>
> >>> I can not reproduce your problem, it works fine here. Could you post
> the
> >>> full code of a simplified driver which triggers the problem ?
> >>>
> >>>
> >>> --
> >>>                                                                 Gilles.
> >>>
> >>
> >> Sure, please find it attached. It's just the standard atmel_spi.c with
> >> task_init command added in atmel_spi_probe() function.
> >>
> > Whatever happened to "simplified"? Please try to reduce your code to the
> > minimum code which triggers the bug. By doing so, you may even find the
> > problem yourself.
> >
> For instance, following your bug report, I wrote the following module:
>
> #include <rtdm/rtdm_driver.h>
>
> static rtdm_task_t t;
>
> void xx_start_transfer(void *arg)
> {
>         rtdm_task_wait_period();
>         rtdm_printk("!!!!!!!!!!!tick!\n");
> }
>
> int init(void)
> {
>         rtdm_task_init(&t, "spi_transfer", xx_start_transfer, NULL, 99,
> 100000000);
>         return 0;
> }
>
> module_init(init);
> MODULE_LICENSE("GPL");
>
> Which works here. As I said, you can confirm whether rtdm_task_init
> works for your configuration by launching latency -t 1 -p 100000
>
> --
>                                                                 Gilles.
>

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/06/2014 11:47 PM, Nima Nourozi wrote:
> I'm not seeing the latency command on my board. Is it part of xenomai? I'm
> using buildroot for my filesystem.

It may not be installed in /usr/bin

Try "xeno latency"


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

On Mon, Jan 6, 2014 at 2:48 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 01/06/2014 11:47 PM, Nima Nourozi wrote:
> > I'm not seeing the latency command on my board. Is it part of xenomai?
> I'm
> > using buildroot for my filesystem.
>
> It may not be installed in /usr/bin
>
> Try "xeno latency"
>
>
> --
>                                                                 Gilles.
>

Gilles, good news!

I was about to report back that the "simplified SPI code" was throwing the
same exception before I messed around in the kernel a little bit more and
turned off VFP feature and low and behold the task is working now!!
Hurray!! I don't know why VFP was causing all this headache but I'm glad
it's working.

Thanks everybody for all help!

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/09/2014 03:51 AM, Nima Nourozi wrote:
> On Mon, Jan 6, 2014 at 2:48 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/06/2014 11:47 PM, Nima Nourozi wrote:
>>> I'm not seeing the latency command on my board. Is it part of xenomai?
>> I'm
>>> using buildroot for my filesystem.
>>
>> It may not be installed in /usr/bin
>>
>> Try "xeno latency"
>>
>>
>> --
>>                                                                 Gilles.
>>
> 
> Gilles, good news!
> 
> I was about to report back that the "simplified SPI code" was throwing the
> same exception before I messed around in the kernel a little bit more and
> turned off VFP feature and low and behold the task is working now!!
> Hurray!! I don't know why VFP was causing all this headache but I'm glad
> it's working.
> 
> Thanks everybody for all help!

That is totally unexpected. Turning on or off VFP on AT91 should not
change anything, since this processor does not have a VFP unit, as far
as I can tell, or does it have one?

Please post the simplified code so that I can test it on AT91SAM9263.


-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/09/2014 03:51 AM, Nima Nourozi wrote:
> On Mon, Jan 6, 2014 at 2:48 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 01/06/2014 11:47 PM, Nima Nourozi wrote:
>>> I'm not seeing the latency command on my board. Is it part of xenomai?
>> I'm
>>> using buildroot for my filesystem.
>>
>> It may not be installed in /usr/bin
>>
>> Try "xeno latency"
>>
>>
>> --
>>                                                                 Gilles.
>>
> 
> Gilles, good news!
> 
> I was about to report back that the "simplified SPI code" was throwing the
> same exception before I messed around in the kernel a little bit more and
> turned off VFP feature and low and behold the task is working now!!
> Hurray!! I don't know why VFP was causing all this headache but I'm glad
> it's working.
> 
> Thanks everybody for all help!

Actually, what the VFP changes is the size of rtdm_task_t, so if the
behaviour of your driver depends on the size of rtdm_task_t, there is
definitely something wrong (like for instance an rtdm_task_t put on
stack). So, again:

please re-enable VFP and test xeno latency -t 1
to see if rtdm_task_init works on your system

please send an as reduced as possible piece of code which allows to
reproduce the problem. The reason to reduce it as much as possible is to:
- be sure of exactly what sequence of calls causes the problem;
- allow people helping you to grasp quickly what this sequence of calls is.

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Gilles Chanteperdrix]

On 01/09/2014 10:21 AM, Gilles Chanteperdrix wrote:
> On 01/09/2014 03:51 AM, Nima Nourozi wrote:
>> On Mon, Jan 6, 2014 at 2:48 PM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> On 01/06/2014 11:47 PM, Nima Nourozi wrote:
>>>> I'm not seeing the latency command on my board. Is it part of xenomai?
>>> I'm
>>>> using buildroot for my filesystem.
>>>
>>> It may not be installed in /usr/bin
>>>
>>> Try "xeno latency"
>>>
>>>
>>> --
>>>                                                                  Gilles.
>>>
>>
>> Gilles, good news!
>>
>> I was about to report back that the "simplified SPI code" was throwing the
>> same exception before I messed around in the kernel a little bit more and
>> turned off VFP feature and low and behold the task is working now!!
>> Hurray!! I don't know why VFP was causing all this headache but I'm glad
>> it's working.
>>
>> Thanks everybody for all help!
>
> Actually, what the VFP changes is the size of rtdm_task_t,

Ok, now that I come to think about it, enabling CONFIG_XENO_HW_FPU with 
CONFIG_VFP unconditionally uses VFP instructions during the context 
switch. Since this configuration does not make sense for any of the 
armv4 and armv5 processors supported by Xenomai, we will add a check at 
runtime so that xenomai will refuse starting in that case.

Regards.

-- 
					    Gilles.

Re: [Xenomai] rtdm_task_init call freezes the system

[Nima Nourozi]

I forgot to add that my chip is AT91SAM9260