This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001160] FIQ can trash stack when interrupting IRQ


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001160

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2011-03-01 00:06:25 GMT ---
(In reply to comment #3)
> Absolutely valid comments. I do not believe it makes sense to make the fix a
> CDL option as it would not make sense to use FIQ without the fix. It is a
> disaster waiting to happen. It does make sense to make the whole FIQ a CDL
> option though.

Glad we agree :-).

> I see two objectives (apart form not using FIQ at all):
> 1) The FIQ happens to be hardwired to some function in an ARM chip and it is
> not possible to avoid using it. In that case you would want the FIQ code with
> the proposed fix.

The processor HAL could and should provide the FIQ handler in the form of a
VSR, not a C level interrupt handler. Usually a FIQ is a FIQ (not an IRQ) for a
good reason, and should be handled quickly, and I wouldn't expect that to be
different here.

> 2) You need the FIQ to do something really high priority, low latency. In that
> case the user might want to disable eCos FIQ handling all together, modify the
> HAL interrupt functions to not touch the F bit and likewise modify Vectors.s to
> not touch the F bit.

I see that point yes. The problem there is what happens when the user _does_
want the FIQ handler to interact with the rest of the system in some way, which
will probably lead to wanting to disable FIQs as well as IRQs *some*times.
Having a single HAL_DISABLE_INTERRUPT() interface is not enough.

On the other hand, this sort of problem may be too hard to solve at any generic
level, so leaving it to the user to decide at CDL level maybe is the best
course.

> option 2) has been discussed on the forums and we have at some point done
> something like this ad-hoc for audio processing but have not made it generic
> enough to be part of a release. We would love to do that with some help.
> 
> It could be nice with a CDL option selecting:
> - No eCos FIQ handling.
> - Standard eCos FIQ handling (FIQ morphs into IRQ)
> - FIQ independent of eCos (no kernel calls allowed)

Given that description, the first and third seem the same, given it will always
be possible to set a FIQ VSR.

Just to clarify what I believe you are getting at:
- Standard eCos FIQ handling (FIQ morphs into IRQ)
- No eCos FIQ handling. Enable/disable interrupts also disables FIQs.
- No eCos FIQ handling. Enable/disable interrupts does not mask FIQs (does not
change F bit), which instead must be dealt with (masked/unmasked) by user
manually.

> Maybe the simple first step is to make an option to include the FIQ->isr/dsr or
> not. If not included it will just be a VSR (as suggested by Jonathan Larmour).
> For super low latency requirements one can still manually modify vectors.s and
> the HAL interrupt functions to prevent the F bit from being set.

There are only a few places the F-bit is modified, so hopefully it wouldn't be
hard to address this all at once. Basically nearly every mention of
CPSR_FIQ_DISABLE in the ARM architecture HAL.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]