apology - Re: rtems_semaphore_obtain error

[Jerry Needell]

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.

>
> + 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.
>
> 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?


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