Re: [ECOS] Ctrl-c interrupt priority

Re: [ECOS] Ctrl-c interrupt priority

[Enrico Piria]

> > The answer I gave myself, instead, was the following: the ISR should be run
> > at the highest maskable priority. This avoids race conditions on the
> > hal_saved_interrupt_state variable, that otherwise could be
> > rewritten by the architecture HAL interrupt handling code, during
> > higher priority interrupts.
>
> Most eCos systems don't use nested interrupts, so this is not an
> issue, and the priorities only decide which of several pending
> interrupts gets passed to the CPU next. However, if nested interrupts
> are being used, then yet, it is probably a good idea to make the
> Ctrl-C interrupt higher priority than any others.
> 

> > The answer I gave myself, instead, was the following: the ISR should be run
> > at the highest maskable priority. This avoids race conditions on the
> > hal_saved_interrupt_state variable, that otherwise could be
> > rewritten by the architecture HAL interrupt handling code, during
> > higher priority interrupts.
>
> Most eCos systems don't use nested interrupts, so this is not an
> issue, and the priorities only decide which of several pending
> interrupts gets passed to the CPU next. However, if nested interrupts
> are being used, then yet, it is probably a good idea to make the
> Ctrl-C interrupt higher priority than any others.

Thank you for the answer. I thought a bit more about what
I said in the previous mail, and I found it is wrong.
In fact, when Ctrl-C ISR accesses the hal_saved_interrupt_state
variable, it means that higher priority ISRs have completed,
so the variable points to the correct state.

However, there is the possibility of another race condition, in the
process of breakpoint insertion.
While the Ctrl-C ISR is substituting an instruction with the breakpoint
instruction, a higher priority interrupt can occur, and the related ISR
can execute the code with the partially inserted breakpoint, thus
causing an illegal istruction exception or a crash.

The solution to this can be either:

1) Executing Ctrl-C ISR at the highest possible priority, or
2) disabling the interrupts while inserting the breakpoint, or
3) forcing, through CDL scripts, interrupt nesting to be disabled
when GDB debugging is enabled.

I'm concerned with this issue because I'm working with the ColdFire
architecture, where higher priority interrupts pre-empt
lower priority ones, as soon as they occur.

Regards

Enrico Piria



____________________________________________________________
Navighi a 4 MEGA e i primi 3 mesi sono GRATIS. 
Scegli Libero Adsl Flat senza limiti su http://www.libero.it



--
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] Ctrl-c interrupt priority

[Nick Garnett]

"Enrico Piria" <epiria@libero.it> writes:

> > 
> > > Hello.
> > > 
> > > On architectures supporting interrupt priority levels, at which
> > > priority should the Ctrl-c ISR (the one used to bring up GDB stub)
> > > be run, and why?
> > 
> > I don't think it matters very much. Making it high priority would
> > allow it to preempt any other interrupts. But to be honest, if you
> > have so many lower priority interrupts firing that this actually makes
> > a difference, then you probably have something seriously wrong
> > somewhere.
> > 
> 
> The answer I gave myself, instead, was the following: the ISR should be run
> at the highest maskable priority. This avoids race conditions on the
> hal_saved_interrupt_state variable, that otherwise could be
> rewritten by the architecture HAL interrupt handling code, during
> higher priority interrupts.

Most eCos systems don't use nested interrupts, so this is not an
issue, and the priorities only decide which of several pending
interrupts gets passed to the CPU next. However, if nested interrupts
are being used, then yet, it is probably a good idea to make the
Ctrl-C interrupt higher priority than any others.


-- 
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] Ctrl-c interrupt priority

[Enrico Piria]

>
> > Hello.
> >
> > On architectures supporting interrupt priority levels, at which
> > priority should the Ctrl-c ISR (the one used to bring up GDB stub)
> > be run, and why?
>
> I don't think it matters very much. Making it high priority would
> allow it to preempt any other interrupts. But to be honest, if you
> have so many lower priority interrupts firing that this actually makes
> a difference, then you probably have something seriously wrong
> somewhere.
>

The answer I gave myself, instead, was the following: the ISR should be run
at the highest maskable priority. This avoids race conditions on the
hal_saved_interrupt_state variable, that otherwise could be
rewritten by the architecture HAL interrupt handling code, during
higher priority interrupts.

Is this true?

Thanks

Enrico Piria



____________________________________________________________
Navighi a 4 MEGA e i primi 3 mesi sono GRATIS. 
Scegli Libero Adsl Flat senza limiti su http://www.libero.it



--
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] Ctrl-c interrupt priority

[Nick Garnett]

"Enrico Piria" <epiria@libero.it> writes:

> Hello.
> 
> On architectures supporting interrupt priority levels, at which
> priority should the Ctrl-c ISR (the one used to bring up GDB stub)
> be run, and why?

I don't think it matters very much. Making it high priority would
allow it to preempt any other interrupts. But to be honest, if you
have so many lower priority interrupts firing that this actually makes
a difference, then you probably have something seriously wrong
somewhere.


-- 
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

[ECOS] Ctrl-c interrupt priority

[Enrico Piria]

Hello.

On architectures supporting interrupt priority levels, at which priority should the Ctrl-c ISR (the one used to bring up GDB stub) be run, and why?

Thank you

Enrico Piria



____________________________________________________________
Navighi a 4 MEGA e i primi 3 mesi sono GRATIS. 
Scegli Libero Adsl Flat senza limiti su http://www.libero.it



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