[ECOS] Possible fix for interrupt latency problems on Arm

[ECOS] Possible fix for interrupt latency problems on Arm

[Mike]

I have been looking at why my Arm LPC2220 board occasionally gets 
terrible interrupt latencies. This happens particularly when the 
interrupt I'm interested in occurs whilst ecos is doing processing after 
a TIMER0 (ecos RTC) interrupt.

It seems that interrupt_end() is called from 
hal/arm/arch/current/src/vectors.s with interrupts disabled, whereas it 
looks to me like interrupt_end() has been designed to run with 
interrupts enabled in order for DSRs to be interruptible.

I have modified my own vectors.s by inserting the following immediately 
before the call to interrupt_end():
 // Enable interrupts
 mrs r4,cpsr
 bic r4,r4,#CPSR_IRQ_DISABLE|CPSR_FIQ_DISABLE
 msr cpsr,r4

This seems to work for me, but I would appreciate feedback if this is a 
sane and wise thing to do.

As a newbie, how do I submit such modifications for inclusion in the 
repository?

Thanks,
Mike


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Possible fix for interrupt latency problems on Arm

[Jürgen Lambrecht]

Hello Mike,

I'm just back from holidays - you didn't receive any reply on your mail?

I also use an ARM (ARM7TDMI, eb55 board based), so I'm interested in the
problem. I don't have interrupt latency problems (yet), but I will ask my
colleague.

This is list is normally a good place to start committing modifications..
For the patch, you must send a diff (you can find examples in the mailing
list), and :
"Next time, please send to ecos-patches@ecos.sourceware.org.  Also
include a ChangeLog entry so we don't have to fabricate one."

Kind regards,
Juergen

---
Jürgen Lambrecht
Development Engineer
Televic Transport Systems
http://www.televic.com
Televic NV / SA (main office)  	
Leo Bekaertlaan 1
B-8870 Izegem
Tel: +32 (0)51 303045
Fax: +32 (0)51 310670


Mike wrote:

> I have been looking at why my Arm LPC2220 board occasionally gets 
> terrible interrupt latencies. This happens particularly when the 
> interrupt I'm interested in occurs whilst ecos is doing processing after 
> a TIMER0 (ecos RTC) interrupt.
> 
> It seems that interrupt_end() is called from 
> hal/arm/arch/current/src/vectors.s with interrupts disabled, whereas it 
> looks to me like interrupt_end() has been designed to run with 
> interrupts enabled in order for DSRs to be interruptible.
> 
> I have modified my own vectors.s by inserting the following immediately 
> before the call to interrupt_end():
> // Enable interrupts
> mrs r4,cpsr
> bic r4,r4,#CPSR_IRQ_DISABLE|CPSR_FIQ_DISABLE
> msr cpsr,r4
> 
> This seems to work for me, but I would appreciate feedback if this is a 
> sane and wise thing to do.
> 
> As a newbie, how do I submit such modifications for inclusion in the 
> repository?
> 
> Thanks,
> Mike
> 
> 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Possible fix for interrupt latency problems on Arm

[Nick Garnett]

> Mike wrote:
> 
> > I have been looking at why my Arm LPC2220 board occasionally gets
> > terrible interrupt latencies. This happens particularly when the
> > interrupt I'm interested in occurs whilst ecos is doing processing
> > after a TIMER0 (ecos RTC) interrupt.
> > It seems that interrupt_end() is called from
> > hal/arm/arch/current/src/vectors.s with interrupts disabled, whereas
> > it looks to me like interrupt_end() has been designed to run with
> > interrupts enabled in order for DSRs to be interruptible.
> > I have modified my own vectors.s by inserting the following
> > immediately before the call to interrupt_end():
> > // Enable interrupts
> > mrs r4,cpsr
> > bic r4,r4,#CPSR_IRQ_DISABLE|CPSR_FIQ_DISABLE
> > msr cpsr,r4
> > This seems to work for me, but I would appreciate feedback if this
> > is a sane and wise thing to do.
> > As a newbie, how do I submit such modifications for inclusion in the
> > repository?
> > Thanks,
> > Mike
> >

That change is not a good idea. It can introduce race conditions into
the system. I think you have been lucky so far.

Although interrupt_end() is entered with interrupts disabled, they
will be enabled to call DSRs, that's what
hal_interrupt_stack_call_pending_DSRs does. Interrupts will also be
re-enabled if a context switch is made. So interrupts will get turned
back on within a few microseconds of completing the ISR.

-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Possible fix for interrupt latency problems on Arm

[Mike]

Nick Garnett wrote:
> That change is not a good idea. It can introduce race conditions into
> the system. I think you have been lucky so far.
>
> Although interrupt_end() is entered with interrupts disabled, they
> will be enabled to call DSRs, that's what
> hal_interrupt_stack_call_pending_DSRs does. Interrupts will also be
> re-enabled if a context switch is made. So interrupts will get turned
> back on within a few microseconds of completing the ISR
Hi Nick,

Thanks for getting involved on this one! Prior to my mod, I was indeed 
seeing interrupts being re-enabled in 
hal_interrupt_stack_call_pending_DSRs. However, my problem was that this 
call was being made some time after the interrupt, and resulted in me 
seeing interrupts being disabled for up to 1.3ms, which was simply no good!

I had hoped that the copious use of HAL_DISABLE_INTERRUPTS() in the 
functions called by interrupt_end() would have prevented any race 
conditions. As far as I could determine the only impact of my mod would 
be on the size of interrupt stack needed.

The reason I was hopeful that this was a good mod is that other 
architectures do appear to re-enable ints before the interrupt_end() call.
For example the sparc code does:


    ! First restore the processor interrupt level to that interrupted
    ! (otherwise a task-switch runs at the current PIL) on the assumption
    ! that the ISR dealt with the interrupt source per se, so it is safe
    ! to unmask it, effectively:
    or    %l0, 0x0e0, %l7        ! original PSR and ET (+S,PS)
    wr    %l7, %psr        ! and enable!
    <omitted some code here>

    ! then call interrupt_end( isr_retcode, &intr_object, &regsave )
    ! to unlock the scheduler and do any rescheduling that~s needed.
    ! argument 0 (isr_retcode) is already in place in %o0
    sethi    %hi(hal_interrupt_objects), %l7
    or    %l7, %lo(hal_interrupt_objects), %l7
    ld    [ %l7 + %l3 ], %o1
    add    %sp, 24 * 4, %o2    ! saved regset (maybe tiny)

    .extern interrupt_end
    call    interrupt_end


Likewise for the 68k:


        /*   The  interrupt_end  routine  will   call  the   DSRs  and   
do */
        /* rescheduling when it  decrements the  scheduler lock  from 1  
to */
        /* zero.  In this case, we  do not want  to have interrupts  
masked */
        /* while the DSRs run.   Restore the  interrupt mask  to the  
value */
        /* prior  to  this  interrupt.    Do  not  completely  unmask   
all */
        /* interrupts because this interrupt may be a nested interrupt.  
We */
        /* do not want to lower  the interrupt mask  on the lower  
priority */
        /* 
interrupt.                                                       */

        move.w  (4*3)+int_pres_regs_sz+2(%sp),%d2
        move.w  %d2,%sr

        /*   If the interrupt mask was not previously zero, we want to 
make */
        /* sure that the DSRs to not run and no preemption occurs.  Add 
the */
        /* value of the previous interrupt mask to the scheduler lock.   
If */
        /* the previous mask was  zero, the scheduler  lock will remain  
at */
        /* one and the interrupt  end function will  decrement it to  
zero. */
        /* Otherwise, we want  to prevent the  interrupt end function  
from */
        /* unlocking the scheduler.  We do  this because there is a  
chance */
        /* that someone had  interrupts masked with  the scheduler lock  
at */
        /* zero.  If a  higher  priority  interrupt  occurs,  we  could  
be */
        /* running DSRs and doing preemption with the interrupts 
masked!    */

        and.l   #0x0700,%d2
        lsr.l   #8,%d2
        add.l   %d2,cyg_scheduler_sched_lock

        .extern interrupt_end               /*   Call the  
interrupt_end  C */
        jbsr    interrupt_end               /* routine.  This routine 
might */
                                            /* preempt    the     
currently */
                                            /* running 
thread.              */


Mike





-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] embedded SMTP client

[Laurie Gellatly]

Hi All,
Didn't find too much in the archives for an eCos email client and especially
with SMTP and Auth support.
Has anyone created one they are willing to share?

Thanks			...Laurie:{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Interrupts and new ethernet driver

[Laurie Gellatly]

Hi All,
I'm trying to debug a new Ethernet chip driver for my own Arm board.
I've modelled the new driver code on the SMSC 911cxx driver that was used in
the phycore 2294 dev board I used during development.
I'm using Redboot in RAM to debug the driver.

Although I've seen the stack send a packet or two the system quickly
hangs/crashes.
When I halt the system via JTAG, the PC is around the 10 to 20 addresses.
Removing the network cable the system runs fine until the cable is plugged
in again.
My reading suggests that Redboot does not use interrupts, yet the old driver
appears to
enable and use interrupts. Which is correct?

If interrupts are being used then how/where are the ISR and DSR 'connected'
to the interrupt
as the cyg_driver_interrupt_create seems to be #defined out when using
Redboot?

If interrupts are not to be used with Redboot then I would expect the CPU to
be setup to leave
the interrupt masked off, but that does not seem to be what happens with the
SMSC driver.

When I add diag_printf's to the code things appear to become worse.
Should diag_printf's be OK to use here?

I've looked at ch 51 from the ref manual and I've still got these questions.

Any assistance/suggestions would be most welcome.

Thanks			...Laurie:{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss