apology - Re: rtems_semaphore_obtain error
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Jan 28 18:58:43 UTC 2008
Jerry Needell wrote:
> Joel Sherrill wrote:
>
>> Jerry Needell wrote:
>>
>>> What a bad place to leave out the key word NOT! My apologies for the
>>> pompous way the last line read! I meant to say that I have had very
>>> little experience with the use of semaphores or mutexes. I've sent
>>> some embarrassing posts in the past, but I think this was the worst.
>>>
>>>
>> No big deal. I actually read it correctly.
>>
>> Two odd questions you can answer quickly.
>>
>> + Are you really calling rtems_task_start from an ISR? Or
>> when you say "start", do you mean "unblock"?
>>
> I am calling rtems_task_resume. The task suspends after its execution.
>
>
Good. That is interrupt safe and expected.
>> + Is this the $Id$ of your file
>> cpukit/rtems/src/semtranslatereturncode.c?
>>
>> * $Id: semtranslatereturncode.c,v 1.12.2.1 2007/12/21 15:23:01 joel
>> Exp $
>>
> my version has:
> * $Id: semtranslatereturncode.c,v 1.12 2006/10/30 22:21:23 joel Exp $
> I suppose I should update.
>
Wouldn't hurt.
>> There was a previous version of this file which for semaphores
>> incorrectly
>> used the maximum core mutex status instead of the maximum core
>> semaphore status. I don't think this would be a problem because the
>> maximum core mutex status is greater than the maximum core semaphore
>> one but it is a possibility.
>> I suspect a sequence of things:
>>
>> + You shouldn't call task start from an ISR. That by itself could cause
>> problems. I am not 100% sure of what though.
>> + A task start extension could be doing something really illegal from
>> an ISR. Consider termios mutexes, etc. That could trip weird things.
>>
>> + If you are doing it repeatedly, task start should return
>> INCORRECT_STATE.
>>
>>
> I think I have found out what was happening. The task was actually
> executing far longer than I had expected and a second Interrupt was
> occuring before completion of the previous cycle. This is not supposed
> to ever happen and I need to do a better job of handling the error
> condition if it does. The problem does not occur if I restrict the
> execution time of the task to reasonable limits. Sorry about the false
> alarm. I think rtems was handling the situation as well as could be
> expected?
>
>
Yes. suspend/resume do not nest so the incorrect_state
error was appropriate. As was the missed resume.
A counting semaphore is a good alternative if you are
getting behind a little.
-joel
> Thanks - Jerry
>
>
>
>> --joel
>>
>>> -Jerry
>>> On Jan 25, 2008, at 3:15 PM, Jerry Needell wrote:
>>>
>>>
>>>
>>>> Sorry for misinformation , but I now see that the
>>>> condition :CORE_MUTEX_STATUS_CEILING_VIOLATED will result in the
>>>> Internal error. So my real question is, does anyone have any tips
>>>> for tracking this down? I have (obviously) had much experience with
>>>> the semaphore handler.
>>>> thanks
>>>> - Jerry
>>>>
>>>>
>>>>
>>>> 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 */
>>>>>
>>>>> 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
>>>>>
>>>>> - Jerry
>>>>>
>>>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>
>
More information about the users
mailing list