[Xenomai] rt_intr_wait bug during debugging

[Xenomai] rt_intr_wait bug during debugging

[Paolo Minazzi]

Hi to all,
the problem arise when I debug an application that uses an external 
interrupt.
Below there is a sample (pseudo) code that show how I can see the problem.
The irq stuff is related on my specific machine, so I think it is not 
important
give details about GPIO programming and interrupt clear (CLEAR_IRQ).

To see the problem :
1. I put a breakpoint on the usleep
2. I countinue to send "c" to stop always in the breakpoint.

When all is OK the cnt grows up.

Sometime, after several "c", I encounter the bug.
At this point the cnt is always the same and stops to grow up.
This happen because the irq line is disabled ! I check it seeing the VIC 
register.

I verified that if I put only a breakpoint in the
     asm("nop")
the irq line in the VIC register is disabled. This means that xenomai 
disable the irq line because
I enabled the irq line before with
     rt_intr_enable(&int_desc);
When restart with "c", xenomai is able to enable again the irq line.

For some reason xenomai sometimes does not enable irq line anymore and 
the code
in blocked in the
     rt_intr_wait(&int_desc, TM_INFINITE);
line.

If I enter in the bug condition and manually enable the irq line 
(programming the VIC register)
all works again without problem. If I continue my test I will re-enter 
in the bug condition ...

Only a dubt : in the xenomai example

http://www.xenomai.org/documentation/xenomai-2.4/html/api/user__irq_8c-example.html#a1 


there is not the rt_intr_enable in the irq_server. I don't know if it is 
out problem or not.

I tried to debug and I have some log, but for me it is difficult 
understand the real source of the
bug. I have a system on which I can see the problem with a minimal effort.

To be clear, there is no problem executing the xenomai application 
without debugger.

Regards
Paolo Minazzi






######################################################################################### 

void irq_server(void *cookie)
{
         while (1)
         {
                 rt_intr_enable(&int_desc);

                 asm("nop");

                 rt_intr_wait(&int_desc, TM_INFINITE);

                 CLEAR_IRQ();

                 cnt++;
         }
}
void InitIrq(void)
{
         init_irq_fujitsu();

         rt_intr_create(&int_desc, IRQNAME, IRQNUMBER, I_PROPAGATE );

         rt_task_create(&server_desc, "Irq2ms", TASK_STKSZ, TASK_PRIO, 
TASK_MODE);

         rt_task_start(&server_desc, &irq_server, NULL);

         enable_irq_fujitsu();
}

int main(int argc, char* argv[])
{
         mlockall(MCL_CURRENT|MCL_FUTURE);

         rt_timer_set_mode ( 0 );
         rt_task_set_mode(0, 0, /* T_WARNSW ,*/ NULL);

         MapRegistersARM();

         InitIrq();

         while(1)
         {
                 printf("[ %4d ]\n",cnt);
  ======>        usleep(10000);
         }
}
######################################################################################### 

Re: [Xenomai] rt_intr_wait bug during debugging

[Gilles Chanteperdrix]

On 09/23/2013 10:48 AM, Paolo Minazzi wrote:
> Hi to all,
> the problem arise when I debug an application that uses an external 
> interrupt.
> Below there is a sample (pseudo) code that show how I can see the problem.
> The irq stuff is related on my specific machine, so I think it is not 
> important
> give details about GPIO programming and interrupt clear (CLEAR_IRQ).

Could you try reproducing this issue with a recent I-pipe patch? Say the
I-pipe patch for Linux 3.5 or 3.8?


-- 
                                                                Gilles.

Re: [Xenomai] rt_intr_wait bug during debugging

[Paolo Minazzi]

Il 23/09/2013 20.25, Gilles Chanteperdrix ha scritto:
> On 09/23/2013 10:48 AM, Paolo Minazzi wrote:
>> Hi to all,
>> the problem arise when I debug an application that uses an external
>> interrupt.
>> Below there is a sample (pseudo) code that show how I can see the problem.
>> The irq stuff is related on my specific machine, so I think it is not
>> important
>> give details about GPIO programming and interrupt clear (CLEAR_IRQ).
> Could you try reproducing this issue with a recent I-pipe patch? Say the
> I-pipe patch for Linux 3.5 or 3.8?
>
>
I see the problem with xenomai 2.5.6, linux kernel 2.6.31.8.
I cannot try with a new i-pipe.

I realize that the issue is very closed to our arm board and our porting 
of xenomai.
I think that timers and tasks related to time are more general, while 
tasks connected to
irq line are more specific to hardware and porting. So it is difficult 
reproduce it.

What I'd like to know if it is normal do it in user space (directly 
programming the registers) both
- enable at every cycle the interrupt on the line
- ack the interrupt

The xenomai example you give in the documentation does not show these 
steps,
maybe because this should be done in kernel space.

Thanks for support,

Regards

Paolo Minazzi

Re: [Xenomai] rt_intr_wait bug during debugging

[Philippe Gerum]

On 09/23/2013 10:48 AM, Paolo Minazzi wrote:
> Hi to all,
> the problem arise when I debug an application that uses an external
> interrupt.
> Below there is a sample (pseudo) code that show how I can see the problem.
> The irq stuff is related on my specific machine, so I think it is not
> important
> give details about GPIO programming and interrupt clear (CLEAR_IRQ).
>
> To see the problem :
> 1. I put a breakpoint on the usleep
> 2. I countinue to send "c" to stop always in the breakpoint.
>

Unless you enabled non-stop mode for GDB, breakpointing the main thread 
will stop all threads, including your IRQ server. Interrupts won't be 
acked the way they should, if the relevant code lives in userland. This 
may cause all sorts of weird behaviors (*).

This is why we strongly recommend managing interrupt delivery from a 
RTDM driver - it does not have to be complex, and NOT from userland. 
This driver may then expose an interface to userland for receiving IRQ 
notifications (read, ioctl, whatever fits).

(*) You may want to check your kernel log, in case the Xenomai core 
decided to disable the interrupt line to prevent an IRQ storm.

-- 
Philippe.