rtems_semaphore_obtain error

Jerry Needell jerry.needell at unh.edu
Sat Jan 26 08:06:09 CST 2008

On Jan 25, 2008, at 5:54 PM, Joel Sherrill wrote:

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

Where is the mutex being obtained? None of my code requests it.

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

The task is started by an ISR. Is this a potential problem? Am I  
missing something that must be done to start tasks from ISRs?

> I have seen weird problems when this is done.
Again, I'm not clear on what you are referring to here as my code is  
not "doing anything" (intentionally) with mutexes.


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

Jerry Needell -- jerry.needell at unh.edu   telephone 603 862 2732
University of New Hampshire
Space Science Center - Morse Hall
39 College Road
Durham NH 03824

More information about the rtems-users mailing list