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