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:
>> 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
>> settings? It is also the highest priority task. There application
>> well until this task is required to execute a slightly longer step
>> 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
>>>> 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
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