* [ECOS] Possible fix for interrupt latency problems on Arm @ 2006-07-14 11:50 Mike 2006-07-31 8:32 ` Jürgen Lambrecht ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Mike @ 2006-07-14 11:50 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Possible fix for interrupt latency problems on Arm 2006-07-14 11:50 [ECOS] Possible fix for interrupt latency problems on Arm Mike @ 2006-07-31 8:32 ` Jürgen Lambrecht 2006-07-31 10:21 ` Nick Garnett 2006-08-08 8:59 ` [ECOS] embedded SMTP client Laurie Gellatly 2006-10-16 11:33 ` [ECOS] Interrupts and new ethernet driver Laurie Gellatly 2 siblings, 1 reply; 6+ messages in thread From: Jürgen Lambrecht @ 2006-07-31 8:32 UTC (permalink / raw) To: eCos Discussion 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Possible fix for interrupt latency problems on Arm 2006-07-31 8:32 ` Jürgen Lambrecht @ 2006-07-31 10:21 ` Nick Garnett 2006-08-03 15:37 ` Mike 0 siblings, 1 reply; 6+ messages in thread From: Nick Garnett @ 2006-07-31 10:21 UTC (permalink / raw) To: eCos Discussion > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Possible fix for interrupt latency problems on Arm 2006-07-31 10:21 ` Nick Garnett @ 2006-08-03 15:37 ` Mike 0 siblings, 0 replies; 6+ messages in thread From: Mike @ 2006-08-03 15:37 UTC (permalink / raw) To: eCos Discussion; +Cc: Nick Garnett 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, ®save ) ! 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] embedded SMTP client 2006-07-14 11:50 [ECOS] Possible fix for interrupt latency problems on Arm Mike 2006-07-31 8:32 ` Jürgen Lambrecht @ 2006-08-08 8:59 ` Laurie Gellatly 2006-10-16 11:33 ` [ECOS] Interrupts and new ethernet driver Laurie Gellatly 2 siblings, 0 replies; 6+ messages in thread From: Laurie Gellatly @ 2006-08-08 8:59 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] Interrupts and new ethernet driver 2006-07-14 11:50 [ECOS] Possible fix for interrupt latency problems on Arm Mike 2006-07-31 8:32 ` Jürgen Lambrecht 2006-08-08 8:59 ` [ECOS] embedded SMTP client Laurie Gellatly @ 2006-10-16 11:33 ` Laurie Gellatly 2 siblings, 0 replies; 6+ messages in thread From: Laurie Gellatly @ 2006-10-16 11:33 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-10-16 11:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-07-14 11:50 [ECOS] Possible fix for interrupt latency problems on Arm Mike 2006-07-31 8:32 ` Jürgen Lambrecht 2006-07-31 10:21 ` Nick Garnett 2006-08-03 15:37 ` Mike 2006-08-08 8:59 ` [ECOS] embedded SMTP client Laurie Gellatly 2006-10-16 11:33 ` [ECOS] Interrupts and new ethernet driver Laurie Gellatly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).