rtems_semaphore_obtain error

[Joel Sherrill <joel.sherrill@OARcorp.com>]

Jerry Needell wrote:
> Till,
>     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
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>       
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>