"Can't obtain network semaphore"
Steve Holle
sholle at link-comm.com
Fri Dec 17 15:35:44 UTC 2004
I have a suspect in the investigation of this problem and I would like to
run it by you guys to see what you think.
To break when the _Thread_Executing->Wait.return_code gets set instead of
when it finally gets checked, I first broke on the panic message and copied
down the address in the _Thread_Executing pointer and restarted the
program. I then dereferenced the pointer as follows :
((Thread_Control_struct *)0x600600)->Wait.return_code
I set a hardware watchpoint on the resulting dereference and then set a
condition on that hardware watchpoint of :
((Thread_Control_struct *)0x600600)->Wait.return_code==4
I then started the program and it eventually broke on coremsgseize.c:136
which is the return from the _CORE_message_queue_Seize routine. On line
123 of that routine, the following lines of code is executed :
executing->Wait.return_code =
CORE_MESSAGE_QUEUE_STATUS_UNSATISFIED_NOWAIT ;
return ;
The CORE_MESSAGE_QUEUE_STATUS_UNSATISFIED_NOWAIT enum results in a 4 in the
executing->Wait.return_code and executing at this point resolves to an
address of 0x600600.
The backtrace at this point is as follows :
#3 0x000677f6 in streaming_audio_dma_interrupt() at
ConfigDSPInterrupts.cc:33
#2 0x0004410c in StreamingAudioNetworkToCodecGetData()
at StreamingAudio.cc:139
#1 0x00117aea in rtems_message_queue_receive () at
msgreceive.c:88
#0 0x0012ab4c in _Core_message_queue_Seize () at
coremsgseize.c:136
Obviously, the rtems_message_queue_receive function is being called from
and interrupt. The interrupt is set up, as far as I can discern, in a
conforming manner, using rtems_interrupt_catch. It is entirely possible
that I am misusing the rtems_message_queue_receive function incorrectly
from an interrupt.
Is it legal to call rtems_message_queue_receive from an interrupt?
Are there any special precautions in setting up a queue to be used within
an interrupt?
If anyone would like screenshots or listing of any sections of my code,
please let me know and I will email them to you.
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle at link-comm.com
More information about the users
mailing list