"Can't obtain network semaphore"

[Joel Sherrill <joel@OARcorp.com>]

Steve Holle wrote:
> I bit the bullet and undefed RTEMS_FAST_MUTEX and recompiled this 
> morning and now I get the error message :
> RTEMS: Can't obtain network semaphore: `object deleted while waiting'
> 
> Does this give us any more details?
> How can I trap on that specific semaphore being deleted, as I don't 
> think it ever should.

It can only be deleted by a call to rtems_semaphore_delete.  That
message indicates that it explicitly was deleted -- if you are getting
that error, it is highly unlikely that is is a simply corruption
issue.  Unless some piece of code has the wrong Id and is deleting
it accidentally.  Breaking at semaphore_delete after the system
is up is still important.

This seems especially weird since don't see a delete on the 
networkSemaphore.

Just for double checking purposes and making this easier
to break on, you might want to modify 
cpukit/src/semtranslatereturncode.c to take a different path
when unsuccessful so you will have a very specific line to
break on.  You could even go so far as adding "if error
is object deleted, call dummy function so I can break on it."

--joel

> At 03:22 PM 12/15/2004, Eric Norum wrote:
> 
>> Joel Sherrill  wrote:
>>
>>> I still wonder if there is really any value to not calling the
>>> real semaphore services.  I thought the direct use of score services
>>> was just temporary for comparison and speed improvement until
>>> we had the optimizations in semaphore.
>>> Chris/Eric what do you guys remember?
>>
>>
>> IIRC we put in the 'fast mutex' stuff because it made a significant 
>> impact on the network performance (for EPICS at least).   Perhaps it's 
>> no longer the case.  I'd be happy to remove the fast mutex stuff -- it 
>> always felt a little like I was poking into places I ought not....
>>
>> -- 
>> Eric Norum                                 norume at aps.anl.gov
>> Advanced Photon Source                     Phone: (630) 252-4793
>> Argonne National Laboratory
> 
> 
> Steve Holle
> Link Communications, Inc.
> 1035 Cerise Rd.
> Billings, MT  59101
> sholle at link-comm.com 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985