Joel Sherrill <joel.sherrill@OARcorp.com>
joel.sherrill at OARcorp.com
Fri Jan 25 16:54:15 CST 2008
Jerry Needell wrote:
> Thank you for the reply. I think you have hit the problem, but I'm
> still a ways from finding it. Since my application is not using the
> semaphore I am trying to figure out how my application can be causing
> the problem. The task I am suspicious of is run with RTEMS_PREEMT and
> RTEMS_INTERRUPT_LEVEL(0) set. Would you expect any from either of these
> settings? It is also the highest priority task. There application runs
> well until this task is required to execute a slightly longer step than
> usual. Agin, any suggestions would be welcome.
By definition, the priority ceiling of a semaphore/mutex is
the priority of the most important task that will attempt
to obtain the mutex.
Is this a priority inheritance or priority ceiling mutex that
is being obtained/released from an ISR? You aren't allowed
to do that since you need a task to have priority and all
obtains/releases of mutexes with those protocols must be
from tasks. If this case, the priority used in the call will
probably be that of the interrupted task.
I have seen weird problems when this is done.
> - Jerry
> Till Straumann wrote:
>> Jerry Needell wrote:
>>> My application is entering Internal_error_Occurred from
>>> rtems_semaphore_obtain. The call to rtems_semaphore obtain is coming
>>> from internally from rtems as I am not using semaphore in my
>>> application. I have not tracked it down yet. thin interesting point
>>> is that in the source for rtems_semaphore_obtain, the las line is:
>>> return RTEMS_INTERNAL_ERROR; /* unreached - only to remove
>>> warnings */
These are gone in the current source. There is actually no
path to that code.
>> This is not the only case where RTEMS_INTERNAL_ERROR
>> is returned. The most likely cause of this type of error
>> is a semaphore being taken from a section of code
>> that is protected from preemption or interrupts.
>> -- Till
>>> but it is being reached!!
>>> Does anyone have any suggestions for potential culprits.
>>> BTW: I am using the sparc leon3 bsp in rtems 4.8
Well that should be fine. :-D
>>> - Jerry
>>> rtems-users mailing list
>>> rtems-users at rtems.com
> rtems-users mailing list
> rtems-users at rtems.com
More information about the rtems-users