rtems_semaphore_obtain error

Jerry Needell jerry.needell at unh.edu
Sat Jan 26 17:58:06 UTC 2008


Joel,
	I don't think I've been making my problem very clear. In the  
application, I have several ISRS and several tasks are are to be  
executed after each ISR is triggered. During initialization, all of  
the tasks are started and each consists of an infinite loop that  
suspends at the bottom. When an ISR triggers, it resumes the  
associated task. Do you see any inherent problem with this scheme that  
can lead to the error condition I am seeing? Is there a better way to  
structure this? I am trying to keep it very simple.
	This application has been working well for quite some time, but the  
error began to occur when the highest priority task began to execute  
somewhat longer than before but still far shorter than the time  
between the ISRS that trigger it. Would it be of concern if the task  
execution time were longer than the RTEMS Tick period?

	Any suggestions are most welcome,
thanks,
Jerry
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.
>
> 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
>>

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






More information about the users mailing list