[Xenomai-help] Loosing serial interrupt

[Xenomai-help] Loosing serial interrupt

[Tomas Kalibera]

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

Hi,

I am having problems with lost serial interrupts. Could you please 
explain to me why this happens ? I am probably missing something 
regarding scheduling in Xenomai...
I prepared a program that triggers the problem, at least on my system.

Thanks,

Tomas

The program works on my system as follows:

1. I run the program, it prints

In interrupt, LStatus: 96
In interrupt, read char, LStatus: 96

[which means that it received a serial interrupt, because the 
transmitter receiver is empty]

2. I send a single character to the program over serial line

3. the program wakes up (10 seconds after (1))

4. the program prints

I-NFO irq=4 hits=1
PIC-ISR:0 PIC-IRR:0 PIC-IMR:128 UART-IIR:4 UART-LSR:97 UART-MSR:176

[which means the interrupt at Xenomai level hit only once, although it 
should have twice, second time because of the received character
  these too lines that repeat indefinitely, the interrupt not coming. 
although interrupts are enabled at PIC level]

I use the "XT-PIC-XT" (8259A) interrupt controller. As far as I know, 
Linux sets up the controller to "edge triggering", but uses 
"handle_level_irq" for it. When received by Xenomai, the interrupt is 
masked and acked at PIC level ( "ack" means EOI at 8259A). When the 
interrupt handling in the program finishes, it unmasks the interrupt. I 
verified  that my 8259A has a latch that can detect the UART interrupt 
even if masked, so that when unmasked again, it can be delivered.





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

#include <stdio.h>
#include <sys/io.h>
#include <unistd.h>

#include <native/task.h>
#include <native/intr.h>
#include <sys/mman.h>

#define BASEPORT 0x3f8
#define IRQ_NUMBER 0x4

RT_INTR intr_desc;
RT_TASK sender_desc, task_main;

inline void nfo() {

  int isr, irr, imr;
  int iir, lsr, msr;
  
  outb(0x0b, 0x20);
  isr = inb(0x20);
  outb(0x0a, 0x20);
  irr = inb(0x20);
  imr = inb(0x21);
  
  iir = inb(BASEPORT +2);
  lsr = inb(BASEPORT +5);
  msr = inb(BASEPORT +6);
  
  fprintf(stderr, "PIC-ISR:%d PIC-IRR:%d PIC-IMR:%d UART-IIR:%d UART-LSR:%d UART-MSR:%d\n",
    isr, irr, imr, iir, lsr, msr);

}

void sender_task (void *cookie) {

  int res;
  
  for(;;) {


    res = rt_intr_wait(&intr_desc, TM_INFINITE);
    
    if (res<=0) {
      perror("rt_intr_wait: ");
      continue;
    }

    fprintf(stderr,"In interrupt, LStatus: %d \n", inb(BASEPORT +5));

    inb(BASEPORT);
    fprintf(stderr,"In interrupt, read char, LStatus: %d \n",
        inb(BASEPORT +5));

    rt_intr_enable( &intr_desc ); 
  }
}

RT_INTR_INFO intr_nfo;

int main(int argc, char **argv) {

  int res,i;
  
  if (iopl(3)) { 
    perror("iopl:");
    return 1;
  }

  mlockall(MCL_CURRENT|MCL_FUTURE);
  
  res = rt_intr_create(&intr_desc, NULL, IRQ_NUMBER, I_NOAUTOENA); 
//  res = rt_intr_create(&intr_desc, NULL, IRQ_NUMBER, 0); 

  if (res) {
    perror("rt_intr_create:");
    return 1;
  }
  
  res = rt_task_create(&sender_desc, NULL, 0, 99, 0);
  if (res) {
    perror("rt_task_create:");
    return 1;
  }
  
  rt_task_start(&sender_desc, &sender_task, NULL);


  outb( 0x00, BASEPORT + 1);
  outb( 0x80, BASEPORT + 3 );
  outb( 0x01, BASEPORT + 0 );
  outb( 0x00, BASEPORT + 1 );
  outb( 0x03, BASEPORT + 3 );

// FIFO on, interrupt after one byte
  outb( 0x7, BASEPORT + 2); 
  
// FIFO off 
  outb( 0x0, BASEPORT + 2); 
  
  outb( 0xb, BASEPORT + 4 ); // force rts on
//  outb( 0x9, BASEPORT + 4 ); // do not force rts

  
  rt_intr_enable( &intr_desc );    
  
  outb( 15, BASEPORT + 1 ); 

  rt_task_shadow( &task_main, NULL, 1, 0);

  while (1) {

      rt_task_sleep(10000000000ULL);
      
      rt_intr_inquire(&intr_desc, &intr_nfo);
      fprintf(stderr,"I-NFO irq=%d hits=%d\n", intr_nfo.irq, intr_nfo.hits);

      nfo();
  }

  fprintf(stderr,"Main: no more characters to send...\n");  

}

Re: [Xenomai-help] Loosing serial interrupt

[Jan Kiszka]

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

Tomas Kalibera wrote:
> Hi,
> 
> I am having problems with lost serial interrupts. Could you please
> explain to me why this happens ? I am probably missing something
> regarding scheduling in Xenomai...
> I prepared a program that triggers the problem, at least on my system.
> 
> Thanks,
> 
> Tomas
> 
> The program works on my system as follows:
> 
> 1. I run the program, it prints
> 
> In interrupt, LStatus: 96
> In interrupt, read char, LStatus: 96
> 
> [which means that it received a serial interrupt, because the
> transmitter receiver is empty]
> 
> 2. I send a single character to the program over serial line
> 
> 3. the program wakes up (10 seconds after (1))
> 
> 4. the program prints
> 
> I-NFO irq=4 hits=1
> PIC-ISR:0 PIC-IRR:0 PIC-IMR:128 UART-IIR:4 UART-LSR:97 UART-MSR:176
> 
> [which means the interrupt at Xenomai level hit only once, although it
> should have twice, second time because of the received character
>  these too lines that repeat indefinitely, the interrupt not coming.
> although interrupts are enabled at PIC level]
> 
> I use the "XT-PIC-XT" (8259A) interrupt controller. As far as I know,
> Linux sets up the controller to "edge triggering", but uses
> "handle_level_irq" for it. When received by Xenomai, the interrupt is
> masked and acked at PIC level ( "ack" means EOI at 8259A). When the
> interrupt handling in the program finishes, it unmasks the interrupt. I
> verified  that my 8259A has a latch that can detect the UART interrupt
> even if masked, so that when unmasked again, it can be delivered.

Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
so you have to enable the appropriate handling at kernel IRQ handler level.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] Loosing serial interrupt

[Karch, Joshua]

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

Tomas,

I assume you mean buffer overruns, right?  What type of CPU board are you using?  I'm using a Geode and it is notoriously bad in terms of non-maskable System Management Interrupts which cause overflows. I had to lower the speed of transmission down to 57600 to avoid the overruns.

Take care,

Josh


-----Original Message-----
From: xenomai-help-bounces@domain.hid on behalf of Jan Kiszka
Sent: Mon 5/5/2008 6:21 PM
To: Tomas Kalibera
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Loosing serial interrupt
 
Tomas Kalibera wrote:
> Hi,
> 
> I am having problems with lost serial interrupts. Could you please
> explain to me why this happens ? I am probably missing something
> regarding scheduling in Xenomai...
> I prepared a program that triggers the problem, at least on my system.
> 
> Thanks,
> 
> Tomas
> 
> The program works on my system as follows:
> 
> 1. I run the program, it prints
> 
> In interrupt, LStatus: 96
> In interrupt, read char, LStatus: 96
> 
> [which means that it received a serial interrupt, because the
> transmitter receiver is empty]
> 
> 2. I send a single character to the program over serial line
> 
> 3. the program wakes up (10 seconds after (1))
> 
> 4. the program prints
> 
> I-NFO irq=4 hits=1
> PIC-ISR:0 PIC-IRR:0 PIC-IMR:128 UART-IIR:4 UART-LSR:97 UART-MSR:176
> 
> [which means the interrupt at Xenomai level hit only once, although it
> should have twice, second time because of the received character
>  these too lines that repeat indefinitely, the interrupt not coming.
> although interrupts are enabled at PIC level]
> 
> I use the "XT-PIC-XT" (8259A) interrupt controller. As far as I know,
> Linux sets up the controller to "edge triggering", but uses
> "handle_level_irq" for it. When received by Xenomai, the interrupt is
> masked and acked at PIC level ( "ack" means EOI at 8259A). When the
> interrupt handling in the program finishes, it unmasks the interrupt. I
> verified  that my 8259A has a latch that can detect the UART interrupt
> even if masked, so that when unmasked again, it can be delivered.

Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
so you have to enable the appropriate handling at kernel IRQ handler level.

Jan



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

Re: [Xenomai-help] Loosing serial interrupt

[Tomas Kalibera]

Hi Joshua,

my problem does not seem to be an overrun. UART reports an ordinary 
receive interrupt - 4, line status is 97 (data ready, both sending 
registers empty).

Tomas



Karch, Joshua wrote:
>
> Tomas,
>
> I assume you mean buffer overruns, right?  What type of CPU board are 
> you using?  I'm using a Geode and it is notoriously bad in terms of 
> non-maskable System Management Interrupts which cause overflows. I had 
> to lower the speed of transmission down to 57600 to avoid the overruns.
>
> Take care,
>
> Josh
>
>
> -----Original Message-----
> From: xenomai-help-bounces@domain.hid on behalf of Jan Kiszka
> Sent: Mon 5/5/2008 6:21 PM
> To: Tomas Kalibera
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Loosing serial interrupt
>
> Tomas Kalibera wrote:
> > Hi,
> >
> > I am having problems with lost serial interrupts. Could you please
> > explain to me why this happens ? I am probably missing something
> > regarding scheduling in Xenomai...
> > I prepared a program that triggers the problem, at least on my system.
> >
> > Thanks,
> >
> > Tomas
> >
> > The program works on my system as follows:
> >
> > 1. I run the program, it prints
> >
> > In interrupt, LStatus: 96
> > In interrupt, read char, LStatus: 96
> >
> > [which means that it received a serial interrupt, because the
> > transmitter receiver is empty]
> >
> > 2. I send a single character to the program over serial line
> >
> > 3. the program wakes up (10 seconds after (1))
> >
> > 4. the program prints
> >
> > I-NFO irq=4 hits=1
> > PIC-ISR:0 PIC-IRR:0 PIC-IMR:128 UART-IIR:4 UART-LSR:97 UART-MSR:176
> >
> > [which means the interrupt at Xenomai level hit only once, although it
> > should have twice, second time because of the received character
> >  these too lines that repeat indefinitely, the interrupt not coming.
> > although interrupts are enabled at PIC level]
> >
> > I use the "XT-PIC-XT" (8259A) interrupt controller. As far as I know,
> > Linux sets up the controller to "edge triggering", but uses
> > "handle_level_irq" for it. When received by Xenomai, the interrupt is
> > masked and acked at PIC level ( "ack" means EOI at 8259A). When the
> > interrupt handling in the program finishes, it unmasks the interrupt. I
> > verified  that my 8259A has a latch that can detect the UART interrupt
> > even if masked, so that when unmasked again, it can be delivered.
>
> Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
> so you have to enable the appropriate handling at kernel IRQ handler 
> level.
>
> Jan
>
>

Re: [Xenomai-help] Loosing serial interrupt

[Tomas Kalibera]

Hi Jan,
> Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
> so you have to enable the appropriate handling at kernel IRQ handler level.
>
> Jan
>   

I'm calling rt_intr_create from user space, so I cannot specify I_EDGE. 
But even if I could, looking at the code I assumed that I_EDGE was only 
applicable together with I_SHARED, and should be only used when I need 
to share and edge IRQ among multiple rt_intr objects/interrupt 
handlers.  Is that correct ?

Tomas


> Tomas Kalibera wrote:
>   
>> Hi,
>>
>> I am having problems with lost serial interrupts. Could you please
>> explain to me why this happens ? I am probably missing something
>> regarding scheduling in Xenomai...
>> I prepared a program that triggers the problem, at least on my system.
>>
>> Thanks,
>>
>> Tomas
>>
>> The program works on my system as follows:
>>
>> 1. I run the program, it prints
>>
>> In interrupt, LStatus: 96
>> In interrupt, read char, LStatus: 96
>>
>> [which means that it received a serial interrupt, because the
>> transmitter receiver is empty]
>>
>> 2. I send a single character to the program over serial line
>>
>> 3. the program wakes up (10 seconds after (1))
>>
>> 4. the program prints
>>
>> I-NFO irq=4 hits=1
>> PIC-ISR:0 PIC-IRR:0 PIC-IMR:128 UART-IIR:4 UART-LSR:97 UART-MSR:176
>>
>> [which means the interrupt at Xenomai level hit only once, although it
>> should have twice, second time because of the received character
>>  these too lines that repeat indefinitely, the interrupt not coming.
>> although interrupts are enabled at PIC level]
>>
>> I use the "XT-PIC-XT" (8259A) interrupt controller. As far as I know,
>> Linux sets up the controller to "edge triggering", but uses
>> "handle_level_irq" for it. When received by Xenomai, the interrupt is
>> masked and acked at PIC level ( "ack" means EOI at 8259A). When the
>> interrupt handling in the program finishes, it unmasks the interrupt. I
>> verified  that my 8259A has a latch that can detect the UART interrupt
>> even if masked, so that when unmasked again, it can be delivered.
>>     
>
>   

Re: [Xenomai-help] Loosing serial interrupt

[Jan Kiszka]

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

Tomas Kalibera wrote:
> Hi Jan,
>> Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
>> so you have to enable the appropriate handling at kernel IRQ handler 
>> level.
>>
>> Jan
>>   
> 
> I'm calling rt_intr_create from user space, so I cannot specify I_EDGE. 
> But even if I could, looking at the code I assumed that I_EDGE was only 
> applicable together with I_SHARED, and should be only used when I need 
> to share and edge IRQ among multiple rt_intr objects/interrupt 
> handlers.  Is that correct ?

Yeah, that was nonsense. It's a shared-IRQ thing, and those won't work 
via the native API anyway.

If you can identify a point when something interesting just happened 
(which means much less than 10 seconds ago), try placing a 
xntrace_user_freeze() at that location and use the I-pipe tracer to 
analyse the history of the system (of the last few milliseconds). That 
can help to understand what does or does not go on at lower levels. Find 
more infos on the tracer in the wiki.

BTW, there is also a test case available for IRQ delivery via 
null-modem, check irqbench. It doesn't use the rt_intr API, but the same 
hardware.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: [Xenomai-help] Loosing serial interrupt

[Tomas Kalibera]

Hi Jan,

the problem was that the previous interrupt was not correctly served 
(IIR was not read). UART still reported the new interrupt in its IIR 
register, but probably did not send the INTR signal to the PIC.

Cheers,

Tomas

Jan Kiszka wrote:
> Tomas Kalibera wrote:
>> Hi Jan,
>>> Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered,
>>> so you have to enable the appropriate handling at kernel IRQ handler 
>>> level.
>>>
>>> Jan
>>>   
>>
>> I'm calling rt_intr_create from user space, so I cannot specify 
>> I_EDGE. But even if I could, looking at the code I assumed that 
>> I_EDGE was only applicable together with I_SHARED, and should be only 
>> used when I need to share and edge IRQ among multiple rt_intr 
>> objects/interrupt handlers.  Is that correct ?
>
> Yeah, that was nonsense. It's a shared-IRQ thing, and those won't work 
> via the native API anyway.
>
> If you can identify a point when something interesting just happened 
> (which means much less than 10 seconds ago), try placing a 
> xntrace_user_freeze() at that location and use the I-pipe tracer to 
> analyse the history of the system (of the last few milliseconds). That 
> can help to understand what does or does not go on at lower levels. 
> Find more infos on the tracer in the wiki.
>
> BTW, there is also a test case available for IRQ delivery via 
> null-modem, check irqbench. It doesn't use the rt_intr API, but the 
> same hardware.
>
> Jan
>