apology - Re: rtems_semaphore_obtain error

[Joel Sherrill]

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

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

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.

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