rtems_semaphore_obtain error

[Jerry Needell]

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.

Thanks,
Jerry

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