[Adeos-main] interrupt latency

[Adeos-main] interrupt latency

[Dirk Roloff]

Hi List,

I ve got the following problem:

I have to write a driver for linux for a receiver-board. 
On this board is an AMCC S5933 pci-controler. Ok on this chip is a fifo (256 
bit).
it has 2 regsiters MWAR (adress for DMA) and MWTC ( byte count for DMA)
i will set both to a buffer - the count will be decemented and if it reaches 
zero i will get an interrupt (IRQ 5). in the drivers handler function i will 
just set MWAR to the next buffer and MWTC to the size of the buffer.
So the board can start new DMA.

Thats the background now the problem:
the fifo, again its 256 bit will be filled by a satalite link with 1Mbit
1024000 bits per second. So i have a maximum of 0.25 milliseconds.
and i have no idea how long it takes to get the pci for the next dma.
But it woks most time, but ca. 10 times in an hour my pc is too slow.
( i think - i am not sure )
So i loose some data. Its a receive only application so i have no handshake 
back in the air.

if you google for interrupt latency - you will find "Linux is no RTOS" - so i 
find rtai and the adeos-patches. Great that sounds like it could work.
untar kernel - patch - compile - crash - compile - read ... read ... 
understand ... ahhhh .... ok i changed the driver.

Create a domain with prio 200 
adeos_virtualize_irq( IRQ 5 )
compile - test .... the same problem .... i lose data ....

My next try to understand whats going on .... create a new module to simulate 
what i think is going on.
i put some soure at the end of this mail.

I registered a linux handler vor irq 4 (serial device)
this is just looping in a long loop doing nothing but using cpu power.
( a cat on ttyS0 will trigger one irq )

i register a handler for all (0-15) irqs on the realtimeside.
while the linux handler is running i am counting the irqs that will be entered 
in there.

at the end of the linux_handler i printk what is captured by the realtime:
IRQ 0 ( timer i think ) 300 times and more ...

and then i see only one other IRQ happening once !!
IRQ 9 ( scsii ) or IRQ 1 (keyboard) or IRQ 12 (mouse)

realy - when i trigger IRQ 4 ( by cat /dev/ttyS0 ) the pc is hanging for about 
a sekond. i am spinning around the mouse and pressing the keyboard.
i will only catch one IRQ.

At the end of the linux handler i read out the pic. the catched irq for 
example 12 is marked out. And i couldn't find why. If i understand the code. 
an incomming IRQ will be acked and put in the ipipe. So new IRQs can happen.
While walking down the ipipe.

Back to my real problem - if there is a driver on the linux side - the ide or 
whatever using long time ( simulated by IRQ 4 ) i will not get in the 
realtime handler for my receiver card.

My goal is: if IRQ 5 is raised - stop doing what ever you are doing - serve 
the board, and after that you have all time you need.

i am working a week on my own, its sunday night and the weekend is also gone.
i real need someone to help me.

thanks

Dirk

ah ... here is now the code pices ( I cut out some stuff )


init_module()
 - request_irq( 4 , linux_handler ) /* my simulation of a long running device 
handler here ist ttyS0 */
 - adeos_register_domain( myRealtime )

in the DomainEntry()
{
 int i;
  for(i=0;i<16;++i) adeos_virtualize_irq( i realtime_handler )

  for(;;) /* dont realy understand - copyed from rtai */
    adeos_suspend_domain();
}

static volatile int linux_irq = 0;
static volatile int irq_count[256];

static void linux_handler()
{
  linux_irq = 1;	/* we are running */
 /* just eating some cpu time - this will hang the linux for 1-2 sekonds */
  for(x=0;x<1000;++x) 
    for(i=0;i<1000000;++i)
      if( x==0)++i;

  linux_irq = 0; /* we are finish */
  /* Ok lets have a look what happend in realtime */
  for( i=0;i<255;++i)
  {
    if( irq_count[i] != 0)
      printk ("linux_irq_handler: irq %d catched %d times\n",i ,irq_count[i]);
  }
}

static void 
realtime_handler ( unsigned int irq )
{
  if(linux_irq != 0)
  {
    ++irq_count[irq]; /* add counter while linux_handler is running */
  }
}

[Adeos-main] interrupt latency

[Dirk Roloff]

Hi List,

I ve got the following problem:

I have to write a driver for linux for a receiver-board. 
On this board is an AMCC S5933 pci-controler. Ok on this chip is a fifo (256 
bit).
it has 2 regsiters MWAR (adress for DMA) and MWTC ( byte count for DMA)
i will set both to a buffer - the count will be decemented and if it reaches 
zero i will get an interrupt (IRQ 5). in the drivers handler function i will 
just set MWAR to the next buffer and MWTC to the size of the buffer.
So the board can start new DMA.

Thats the background now the problem:
the fifo, again its 256 bit will be filled by a satalite link with 1Mbit
1024000 bits per second. So i have a maximum of 0.25 milliseconds.
and i have no idea how long it takes to get the pci for the next dma.
But it woks most time, but ca. 10 times in an hour my pc is too slow.
( i think - i am not sure )
So i loose some data. Its a receive only application so i have no handshake 
back in the air.

if you google for interrupt latency - you will find "Linux is no RTOS" - so i 
find rtai and the adeos-patches. Great that sounds like it could work.
untar kernel - patch - compile - crash - compile - read ... read ... 
understand ... ahhhh .... ok i changed the driver.

Create a domain with prio 200 
adeos_virtualize_irq( IRQ 5 )
compile - test .... the same problem .... i lose data ....

My next try to understand whats going on .... create a new module to simulate 
what i think is going on.
i put some soure at the end of this mail.

I registered a linux handler vor irq 4 (serial device)
this is just looping in a long loop doing nothing but using cpu power.
( a cat on ttyS0 will trigger one irq )

i register a handler for all (0-15) irqs on the realtimeside.
while the linux handler is running i am counting the irqs that will be entered 
in there.

at the end of the linux_handler i printk what is captured by the realtime:
IRQ 0 ( timer i think ) 300 times and more ...

and then i see only one other IRQ happening once !!
IRQ 9 ( scsii ) or IRQ 1 (keyboard) or IRQ 12 (mouse)

realy - when i trigger IRQ 4 ( by cat /dev/ttyS0 ) the pc is hanging for about 
a sekond. i am spinning around the mouse and pressing the keyboard.
i will only catch one IRQ.

At the end of the linux handler i read out the pic. the catched irq for 
example 12 is marked out. And i couldn't find why. If i understand the code. 
an incomming IRQ will be acked and put in the ipipe. So new IRQs can happen.
While walking down the ipipe.

Back to my real problem - if there is a driver on the linux side - the ide or 
whatever using long time ( simulated by IRQ 4 ) i will not get in the 
realtime handler for my receiver card.

My goal is: if IRQ 5 is raised - stop doing what ever you are doing - serve 
the board, and after that you have all time you need.

i am working a week on my own, its sunday night and the weekend is also gone.
i real need someone to help me.

thanks

Dirk

ah ... here is now the code pices ( I cut out some stuff )


init_module()
 - request_irq( 4 , linux_handler ) /* my simulation of a long running device 
handler here ist ttyS0 */
 - adeos_register_domain( myRealtime )

in the DomainEntry()
{
 int i;
  for(i=0;i<16;++i) adeos_virtualize_irq( i realtime_handler )

  for(;;) /* dont realy understand - copyed from rtai */
    adeos_suspend_domain();
}

static volatile int linux_irq = 0;
static volatile int irq_count[256];

static void linux_handler()
{
  linux_irq = 1;	/* we are running */
 /* just eating some cpu time - this will hang the linux for 1-2 sekonds */
  for(x=0;x<1000;++x) 
    for(i=0;i<1000000;++i)
      if( x==0)++i;

  linux_irq = 0; /* we are finish */
  /* Ok lets have a look what happend in realtime */
  for( i=0;i<255;++i)
  {
    if( irq_count[i] != 0)
      printk ("linux_irq_handler: irq %d catched %d times\n",i ,irq_count[i]);
  }
}

static void 
realtime_handler ( unsigned int irq )
{
  if(linux_irq != 0)
  {
    ++irq_count[irq]; /* add counter while linux_handler is running */
  }
}

Re: [Adeos-main] interrupt latency

[Philippe Gerum]

On Mon, 2004-02-23 at 00:35, Dirk Roloff wrote:
> Hi List,
> 
> I ve got the following problem:
> 
> I have to write a driver for linux for a receiver-board. 
> On this board is an AMCC S5933 pci-controler. Ok on this chip is a fifo (256 
> bit).
> it has 2 regsiters MWAR (adress for DMA) and MWTC ( byte count for DMA)
> i will set both to a buffer - the count will be decemented and if it reaches 
> zero i will get an interrupt (IRQ 5). in the drivers handler function i will 
> just set MWAR to the next buffer and MWTC to the size of the buffer.
> So the board can start new DMA.
> 
> Thats the background now the problem:
> the fifo, again its 256 bit will be filled by a satalite link with 1Mbit
> 1024000 bits per second. So i have a maximum of 0.25 milliseconds.
> and i have no idea how long it takes to get the pci for the next dma.
> But it woks most time, but ca. 10 times in an hour my pc is too slow.
> ( i think - i am not sure )
> So i loose some data. Its a receive only application so i have no handshake 
> back in the air.
> 
> if you google for interrupt latency - you will find "Linux is no RTOS" - so i 
> find rtai and the adeos-patches. Great that sounds like it could work.
> untar kernel - patch - compile - crash - compile - read ... read ... 
> understand ... ahhhh .... ok i changed the driver.
> 
> Create a domain with prio 200 
> adeos_virtualize_irq( IRQ 5 )
> compile - test .... the same problem .... i lose data ....
> 
> My next try to understand whats going on .... create a new module to simulate 
> what i think is going on.
> i put some soure at the end of this mail.
> 
> I registered a linux handler vor irq 4 (serial device)
> this is just looping in a long loop doing nothing but using cpu power.
> ( a cat on ttyS0 will trigger one irq )
> 
> i register a handler for all (0-15) irqs on the realtimeside.
> while the linux handler is running i am counting the irqs that will be entered 
> in there.
> 
> at the end of the linux_handler i printk what is captured by the realtime:
> IRQ 0 ( timer i think ) 300 times and more ...
> 
> and then i see only one other IRQ happening once !!
> IRQ 9 ( scsii ) or IRQ 1 (keyboard) or IRQ 12 (mouse)
> 
> realy - when i trigger IRQ 4 ( by cat /dev/ttyS0 ) the pc is hanging for about 
> a sekond. i am spinning around the mouse and pressing the keyboard.
> i will only catch one IRQ.
> 
> At the end of the linux handler i read out the pic. the catched irq for 
> example 12 is marked out. And i couldn't find why. If i understand the code. 
> an incomming IRQ will be acked and put in the ipipe. So new IRQs can happen.
> While walking down the ipipe.
> 
> Back to my real problem - if there is a driver on the linux side - the ide or 
> whatever using long time ( simulated by IRQ 4 ) i will not get in the 
> realtime handler for my receiver card.
> 
> My goal is: if IRQ 5 is raised - stop doing what ever you are doing - serve 
> the board, and after that you have all time you need.
> 
> i am working a week on my own, its sunday night and the weekend is also gone.
> i real need someone to help me.
> 
> thanks
> 
> Dirk
> 
> ah ... here is now the code pices ( I cut out some stuff )
> 
> 
> init_module()
>  - request_irq( 4 , linux_handler ) /* my simulation of a long running device 
> handler here ist ttyS0 */
>  - adeos_register_domain( myRealtime )
> 
> in the DomainEntry()
> {
>  int i;
>   for(i=0;i<16;++i) adeos_virtualize_irq( i realtime_handler )
> 

It would be interesting to know the flags passed to
adeos_virtualize_irq(). In any case, either the 4th arg should pass
IPIPE_PASS_MASK, or you realtime_handler() routine should call
adeos_propagate_irq(irq).

>   for(;;) /* dont realy understand - copyed from rtai */
>     adeos_suspend_domain();
> }
> 
> static volatile int linux_irq = 0;
> static volatile int irq_count[256];
> 
> static void linux_handler()
> {
>   linux_irq = 1;	/* we are running */
>  /* just eating some cpu time - this will hang the linux for 1-2 sekonds */
>   for(x=0;x<1000;++x) 
>     for(i=0;i<1000000;++i)
>       if( x==0)++i;

>   linux_irq = 0; /* we are finish */
>   /* Ok lets have a look what happend in realtime */
>   for( i=0;i<255;++i)
>   {
>     if( irq_count[i] != 0)
>       printk ("linux_irq_handler: irq %d catched %d times\n",i ,irq_count[i]);
>   }
> }
> 
> static void 
> realtime_handler ( unsigned int irq )
> {
>   if(linux_irq != 0)
>   {
>     ++irq_count[irq]; /* add counter while linux_handler is running */
>   }
> }
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> http://mail.nongnu.org/mailman/listinfo/adeos-main
-- 

Philippe.

Re: [Adeos-main] interrupt latency

[Dirk Roloff]

Am Montag, 23. Februar 2004 00:52 schrieb Philippe Gerum:
> On Mon, 2004-02-23 at 00:35, Dirk Roloff wrote:
> > Hi List,
> >
> > I ve got the following problem:
> >
> > I have to write a driver for linux for a receiver-board.
--- schnipp ---- 
>
> It would be interesting to know the flags passed to
> adeos_virtualize_irq(). In any case, either the 4th arg should pass
> IPIPE_PASS_MASK, or you realtime_handler() routine should call
> adeos_propagate_irq(irq).
Philippe:

the exactly code is:
      if( 0 != adeos_virtualize_irq( irq[i], &rt_amcc_irq_handler, NULL, 
IPIPE_PASS_MASK | IPIPE_HANDLE_MASK) )

i want to handle and pass it down the pipe.

But i give propagate a try ... not realy better ... 
Now a second IRQ 4 will be delivert to the linux handler.
Only one IRQ 1 to the realtime (its masked out in PIC  when entering the 
realtime)
Could it be that this will block all other IRQ at PIC level ?

Dirk.

Re: [Adeos-main] interrupt latency

[Philippe Gerum]

On Mon, 2004-02-23 at 03:22, Dirk Roloff wrote:
> Am Montag, 23. Februar 2004 00:52 schrieb Philippe Gerum:
> > On Mon, 2004-02-23 at 00:35, Dirk Roloff wrote:
> > > Hi List,
> > >
> > > I ve got the following problem:
> > >
> > > I have to write a driver for linux for a receiver-board.
> --- schnipp ---- 
> >
> > It would be interesting to know the flags passed to
> > adeos_virtualize_irq(). In any case, either the 4th arg should pass
> > IPIPE_PASS_MASK, or you realtime_handler() routine should call
> > adeos_propagate_irq(irq).
> Philippe:
> 
> the exactly code is:
>       if( 0 != adeos_virtualize_irq( irq[i], &rt_amcc_irq_handler, NULL, 
> IPIPE_PASS_MASK | IPIPE_HANDLE_MASK) )
> 
> i want to handle and pass it down the pipe.
> 
> But i give propagate a try ... not realy better ... 

> Now a second IRQ 4 will be delivert to the linux handler.


That's normal. Either set IPIPE_PASS_MASK if you want Adeos to propagate
the incoming IRQ unconditionally, _or_ don't set it if you want your
handler to decide dynamically of whether the propagation should take
place or not on a per-IRQ basis using adeos_propagate_irq().

> Only one IRQ 1 to the realtime (its masked out in PIC  when entering the 
> realtime)

That's ok too. By default on the x86 port, IRQs are mask & acked upon
receipt before the IRQ flows down the pipeline, except the 8254 timer
which is only acked.

> Could it be that this will block all other IRQ at PIC level ?
> 

Here are the typical actions taken upon IRQ receipt with a single
prioritary domain running above Linux in the pipeline:

hw IRQ =>
	[Adeos primary handler]
		=> mask and ack (from now, IRQ is masked at 8259 level)
		=> pipeline walk (all pending IRQs)
			=> realtime_handler(irq)
				[Your processing]
				adeos_propagate_irq(irq) (unless you set 						              
IPIPE_PASS_MASK)
			=> Linux handler()
				[Linux's do_IRQ(irq)]
				end_irq() (which re-enables the IRQ 					    line at the 8259 level)

If you want to re-enable the IRQ line earlier in the process (i.e.
before Linux's regular handler is run), then you can do this by calling
adeos_control_irq(irq,0,IPIPE_ENABLE_MASK) in your real-time handler. 

You may want to have a look at the Adeos CVS, under linux/examples:
there are a set of testing and measurement programs illustrating how the
pipeline shall be controlled.

Btw: which Adeos version are you using? 

> Dirk.
> 
> 
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> http://mail.nongnu.org/mailman/listinfo/adeos-main
-- 

Philippe.

Re: [Adeos-main] interrupt latency

[Dirk Roloff]

Philippe :
the last question was the best ....

> Btw: which Adeos version are you using?

2.4r10/x86 on a 2.4.24 fresh kernel fom kernel.org.
It was part of the RTAI - i will check the cvs entry ... ops ...
after writing this mail i had a look at cvs ... is see r11 is out and there is a new 
IPIPE_SHARED_MASK - i will have a closer look at this now ....

> >
> > Now a second IRQ 4 will be delivert to the linux handler.
>
> That's normal. Either set IPIPE_PASS_MASK if you want Adeos to propagate
> the incoming IRQ unconditionally, _or_ don't set it if you want your
> handler to decide dynamically of whether the propagation should take
> place or not on a per-IRQ basis using adeos_propagate_irq().

Ok - so set PASS_MASK or use adeos_propagate_irq() should do the same.
But this looks like i miss on IRQ 4 without propagate. I will check this once again.

>
> > Only one IRQ 1 to the realtime (its masked out in PIC  when entering the
> > realtime)
>
> That's ok too. By default on the x86 port, IRQs are mask & acked upon
> receipt before the IRQ flows down the pipeline, except the 8254 timer
> which is only acked.
>
> > Could it be that this will block all other IRQ at PIC level ?
>
> Here are the typical actions taken upon IRQ receipt with a single
> prioritary domain running above Linux in the pipeline:
>
hw IRQ 4 =>
    [Adeos primary handler]
        => mask and ack (from now, IRQ is masked at 8259 level)
        => pipeline walk (all pending IRQs)
            => realtime_handler(irq)
                 [Your processing]
                 adeos_propagate_irq(irq) ( ok dont need have IPIPE_PASS_MASK set)

            => [Linux's do_IRQ(irq)]
                => start Linux handler()

                    ** interupted by hw IRQ 1 =>

                        [Adeos primary handler]
                            => mask and ack (from now, IRQ 4 and 1 is masked at 8259 level)
                            => pipeline walk (all pending IRQs)
                                => realtime_handler(irq)
                                     [Your processing]
                                => !!!!  should leave the pipe because linux stalls it right ?
                                     !!!!  IRQ 1 is marked out so no other IRQ 1 will be delivered by pic
                                     !!!!  shouldnt adeos unmask it ??

                    ** another interupt by hw IRQ 12 (not masked) =>
                        !!!!  Here it looks like adeos [Adeos primary handler] will not entered - why ?
                        !!!!  no realtime_handler(irq) calls are counted

                    ** another interupt by hw IRQ 4 again  (is masked so will be hold by PIC) =>

                => end of Linux handler()
                => end_irq() (which re-enables the IRQ 4 line at the 8259 level)
	    => back in pipeline walk - maybe the second IRQ 4 was delivered to 


So if i undertud this right - adeos dose not take control over the PIC enable/disable funktion in a per domain manner.
So until linux reenable an interrupt its be disabled for other high prio domains.
i just implented a short hack - catch all irqs in realtime and enable them on pic level in there.
Ok i i need a hard reset to bring the system back - I think that dosent work, because linux could not 
handle another irq while in the handler.
So what do you think about a per domain bitmask that will mirror the pic IMR.

in mask_and_ack_8259A() delete 
outb(cached_A1,0xA1); 
and 
outb(cached_21,0x21);
so it dose not mask the IRQ

in __adeos_sync_stage
check and set the mask bit just before calling irq_handler and after this clears it.
This should save us to do not call the same irq handler twice for the same IRQ.

Mhhh ... what about SMP ... maybe the mask should be a per domain per cpu field.

Let me know what you think about this.

>
> If you want to re-enable the IRQ line earlier in the process (i.e.
> before Linux's regular handler is run), then you can do this by calling
> adeos_control_irq(irq,0,IPIPE_ENABLE_MASK) in your real-time handler.

thats ok for my board IRQ but i could not enable all IRQs and so another isr running
in linux will disalow other realtime irqs. see above.

>
> You may want to have a look at the Adeos CVS, under linux/examples:
> there are a set of testing and measurement programs illustrating how the
> pipeline shall be controlled.
>

Dirk.

Re: [Adeos-main] interrupt latency

[Philippe Gerum]

Hi Dirk,

On Mon, 2004-02-23 at 19:06, Dirk Roloff wrote:
> Philippe :
> the last question was the best ....
> 
> > Btw: which Adeos version are you using?
> 
> 2.4r10/x86 on a 2.4.24 fresh kernel fom kernel.org.
> It was part of the RTAI - i will check the cvs entry ... ops ...
> after writing this mail i had a look at cvs ... is see r11 is out and there is a new 
> IPIPE_SHARED_MASK - i will have a closer look at this now ....
> 

Ok. However, r11 behaves exactely the same way than r10 for the part we
are talking of (most of the work between r10 and the current r11
candidates is SMP-related). Shared IRQs might not be what you need here
(i.e. you don't have to share a single IRQ line shared by several
devices handled by different Adeos domains).

> > >
> > > Now a second IRQ 4 will be delivert to the linux handler.
> >
> > That's normal. Either set IPIPE_PASS_MASK if you want Adeos to propagate
> > the incoming IRQ unconditionally, _or_ don't set it if you want your
> > handler to decide dynamically of whether the propagation should take
> > place or not on a per-IRQ basis using adeos_propagate_irq().
> 
> Ok - so set PASS_MASK or use adeos_propagate_irq() should do the same.
> But this looks like i miss on IRQ 4 without propagate. I will check this once again.
> 

Ack.

> >
> > > Only one IRQ 1 to the realtime (its masked out in PIC  when entering the
> > > realtime)
> >
> > That's ok too. By default on the x86 port, IRQs are mask & acked upon
> > receipt before the IRQ flows down the pipeline, except the 8254 timer
> > which is only acked.
> >
> > > Could it be that this will block all other IRQ at PIC level ?
> >
> > Here are the typical actions taken upon IRQ receipt with a single
> > prioritary domain running above Linux in the pipeline:
> >
> hw IRQ 4 =>
>     [Adeos primary handler]
>         => mask and ack (from now, IRQ is masked at 8259 level)
>         => pipeline walk (all pending IRQs)
>             => realtime_handler(irq)
>                  [Your processing]
>                  adeos_propagate_irq(irq) ( ok dont need have IPIPE_PASS_MASK set)
> 
>             => [Linux's do_IRQ(irq)]
>                 => start Linux handler()
> 
>                     ** interupted by hw IRQ 1 =>
> 
>                         [Adeos primary handler]
>                             => mask and ack (from now, IRQ 4 and 1 is masked at 8259 level)
>                             => pipeline walk (all pending IRQs)
>                                 => realtime_handler(irq)
>                                      [Your processing]
>                                 => !!!!  should leave the pipe because linux stalls it right ?

Yes. But still, keep in mind that the IRQ syncer (__adeos_sync_stage())
can be re-entered safely by an IRQ. This is needed because some Linux
IRQ drivers (namely the PC keyboard one using IRQ #1) sit in a busy loop
waiting for subsequent interrupts on behalf of their own interrupt
handler...

>                                      !!!!  IRQ 1 is marked out so no other IRQ 1 will be delivered by pic
>                                      !!!!  shouldnt adeos unmask it ??
> 

Adeos does not re-enable the IRQ line at PIC level because this could
not be the right thing to do under some circumstances: i.e.
level-triggered IRQs. In such a case, re-enabling the IRQs too early may
result in a flood of interrupts until the recipient domain shuts the
source. So the decision to re-enable the IRQ "physically" is left to the
domains, and if no non-Linux domain did it, at least the Linux one does
this by calling the end() method of the interrupt descriptor as usual,
at the end of do_IRQ().

Therefore re-enabling all the interrupt sources in your domain handler
may not be an option. It all depends on the domain logic wrt to the
managed device. The crash you experienced while re-enabling all IRQs
might be related to this fact.

>                     ** another interupt by hw IRQ 12 (not masked) =>
>                         !!!!  Here it looks like adeos [Adeos primary handler] will not entered - why ?
>                         !!!!  no realtime_handler(irq) calls are counted
> 

I'd bet that Adeos primary handler is actually entered, but your domain
might be stalled, so no interrupt could be delivered to it.

>                     ** another interupt by hw IRQ 4 again  (is masked so will be hold by PIC) =>
> 
>                 => end of Linux handler()
>                 => end_irq() (which re-enables the IRQ 4 line at the 8259 level)
> 	    => back in pipeline walk - maybe the second IRQ 4 was delivered to 
> 
> 
> So if i undertud this right - adeos dose not take control over the PIC enable/disable funktion in a per domain manner.
> So until linux reenable an interrupt its be disabled for other high prio domains.
> i just implented a short hack - catch all irqs in realtime and enable them on pic level in there.
> Ok i i need a hard reset to bring the system back - I think that dosent work, because linux could not 
> handle another irq while in the handler.
> So what do you think about a per domain bitmask that will mirror the pic IMR.
> 
> in mask_and_ack_8259A() delete 
> outb(cached_A1,0xA1); 
> and 
> outb(cached_21,0x21);
> so it dose not mask the IRQ

> in __adeos_sync_stage
> check and set the mask bit just before calling irq_handler and after this clears it.
> This should save us to do not call the same irq handler twice for the same IRQ.
> 
> Mhhh ... what about SMP ... maybe the mask should be a per domain per cpu field.
> 
> Let me know what you think about this.
> 

There is a mechanism implemented in Adeos that actually handles the
enable/disable IRQ ops on a per-domain basis. I've posted some
information about this to the RTAI mailing list once, maybe you want to
have a look at it, so we can further discuss this stuff:
https://mail.rtai.org/pipermail/rtai/2003-November/005623.html

> >
> > If you want to re-enable the IRQ line earlier in the process (i.e.
> > before Linux's regular handler is run), then you can do this by calling
> > adeos_control_irq(irq,0,IPIPE_ENABLE_MASK) in your real-time handler.
> 
> thats ok for my board IRQ but i could not enable all IRQs and so another isr running
> in linux will disalow other realtime irqs. see above.

> >
> > You may want to have a look at the Adeos CVS, under linux/examples:
> > there are a set of testing and measurement programs illustrating how the
> > pipeline shall be controlled.
> >
> 
> Dirk.
> 
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> http://mail.nongnu.org/mailman/listinfo/adeos-main
-- 

Philippe.

Re: [Adeos-main] interrupt latency

[Dirk Roloff]

Am Montag, 23. Februar 2004 20:53 schrieb Philippe Gerum:

Hi Philippe 
> Ok. However, r11 behaves exactely the same way than r10 for the part we
> are talking of (most of the work between r10 and the current r11
> candidates is SMP-related). Shared IRQs might not be what you need here
> (i.e. you don't have to share a single IRQ line shared by several
> devices handled by different Adeos domains).

OK 


> >                                      [Your processing]
> >                                 => !!!!  should leave the pipe because
> > linux stalls it right ?
>
> Yes. But still, keep in mind that the IRQ syncer (__adeos_sync_stage())
> can be re-entered safely by an IRQ. This is needed because some Linux
> IRQ drivers (namely the PC keyboard one using IRQ #1) sit in a busy loop
> waiting for subsequent interrupts on behalf of their own interrupt
> handler...

Yes ... a closer look at this function brings light in the dark.
If i remove the SA_INTERRUPT in request_irq() it works as it should.
With SA_INTERRUPT adding a sti()/cli() to the realtime handler will also work.
Its too late to follow whats going on there - and using heavy printk in the 
realtime handler will lock up the system completly.

> > handler] will not entered - why ? !!!!  no realtime_handler(irq) calls
> > are counted
>
> I'd bet that Adeos primary handler is actually entered, but your domain
> might be stalled, so no interrupt could be delivered to it.

Think you win the bet - looks like its stalled by __adeos_sync_stage. 
Very confusing.  

> >
> > in __adeos_sync_stage
> > check and set the mask bit just before calling irq_handler and after this
> > clears it. This should save us to do not call the same irq handler twice
> > for the same IRQ.
> >
> > Mhhh ... what about SMP ... maybe the mask should be a per domain per cpu
> > field.
> >
> > Let me know what you think about this.
>
> There is a mechanism implemented in Adeos that actually handles the
> enable/disable IRQ ops on a per-domain basis. I've posted some
> information about this to the RTAI mailing list once, maybe you want to
> have a look at it, so we can further discuss this stuff:
> https://mail.rtai.org/pipermail/rtai/2003-November/005623.html

Yes great post - i found it already googlin around. But this time i read it 
twice. :-)

> > > If you want to re-enable the IRQ line earlier in the process (i.e.
> > > before Linux's regular handler is run), then you can do this by calling
> > > adeos_control_irq(irq,0,IPIPE_ENABLE_MASK) in your real-time handler.

I think that was the wrong way.

I will do some more research tomorow. Now i will interrupt my work for a few 
hours sleep.

Dirk.