Interrupt Problems (again).

Gedare Bloom gedare at gwu.edu
Fri Feb 12 17:55:43 UTC 2010


I haven't been using RTEMS that long, so I don't have much advice for
you, but I did have one thought to share.

Perhaps something strange is going on with a CPU dependent
implementation of _ISR_Is_in_progress. Try this:
 > cd ${RTEMS}/cpukit/score/cpu/powerpc/rtems
 > grep -r CPU_PROVIDES_ISR_IS_IN_PROGRESS *

If you get back something that says TRUE, that gives you something
else to look for. score relies on _ISR_Nest_level to determine whether
or not an interrupt is happening, but I suppose a mismatch between
_ISR_Nest_level and the result of rtems_interrupt_is_in_progress()
could be caused by a port that provides an alternate implementation of
_ISR_Is_in_progress.

AFAIK there aren't any ports that actually use this option in the
current release...

-Gedare

On Fri, Feb 12, 2010 at 11:47 AM, Nick Thomas <nick.thomas at pixsan.com> wrote:
> Hi,
>
> I am still having problems with interrupts.
>
> I reported a while ago that rtems_interrupt_is_in_progress() was returning
> the wrong value occasionally.
> Now, I see that I am getting an error 18 (RTEMS_CALLED_FROM_ISR) at a place
> in the code that definitely back-traces to a task!
>
> At the point of the crash I see that _ISR_Nest_level is zero, and
> _Thread_Dispatch_disable_level is 1 .
>
> I am using RTEMS 4.7.1 on a PowerPC 405, if that helps.
>
> I know that RTEMS 4.7.1 is quite old now, but I don't realistically have the
> ability to upgrade at this point in the project.
>
>
> Any help/comments/suggestions welcomed.
>
>
> Regards
>
> Nick
>
> -----------------------------
> Nick Thomas
> Email: nick.thomas at pixsan.com
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>



More information about the users mailing list