[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
apology - Re: rtems_semaphore_obtain error
- Date: Mon, 28 Jan 2008 13:18:30 -0500
- From: jerry.needell at unh.edu (Jerry Needell)
- Subject: apology - Re: rtems_semaphore_obtain error
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
> * $Id: semtranslatereturncode.c,v 22.214.171.124 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
> 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
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
Thanks - 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.
>>> - 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
>> rtems-users mailing list
>> rtems-users at rtems.com