<html><head><meta http-equiv=Content-Type content="text/html; charset=UTF-8"><META name="Author" content="GroupWise WebAccess"><style type="text/css">
body p
{
margin: 0px;
}
</style></head><body style='font-family: Helvetica, Arial, sans-serif; font-size: 13px; '><div id="GroupWiseSection_1548938803000_amonteverde@invap.com.ar_8EED366004520000A9B859CA9D625ECE_" class="GroupWiseMessageBody"><div>Hi Sebastian, Thank you for your prompt response.<br><br>> I don't think this is correct. If you call _MPCI_Send_request_packet(),<br>> then the ownership of this packet is transferred to the implementation<br>> of this function. With the shared memory driver, the packet is freed by<br>> the receiver, see Shm_Free_envelope()."<br><br>If
you think that it's not correct, we can move the returning of the
packet inside _MPCI_Send_request_packet() but the reason why we return
the packet outside _MPCI_Send_request_packet() is because we were
focalized in queue behaviour and a change inside
_MPCI_Send_request_packet() is a broad solution with an unknown effect
for the test.<br><br>Regarding "the packet is freed by the receiver, see
Shm_Free_envelope()", by looking at the code and running the code step
by step with jtag, the core0 (the owner of the queue) does not return
the packet in any case.<br>The core0 MPCI handler for the receive request is:<br><br>_Message_queue_MP_Process_packet()<br>case MESSAGE_QUEUE_MP_RECEIVE_REQUEST:<br><br> the_packet->Prefix.return_code = rtems_message_queue_receive(<br> the_packet->Prefix.id,<br> the_packet->Buffer.buffer,<br> &the_packet->size,<br> the_packet->option_set,<br> the_packet->Prefix.timeout<br> );<br><br> if ( the_packet->Prefix.return_code != RTEMS_PROXY_BLOCKING )<br> _Message_queue_MP_Send_response_packet(<br> MESSAGE_QUEUE_MP_RECEIVE_RESPONSE,<br> the_packet->Prefix.id,<br> _Thread_Executing<br> );<br> break;<br> <br>The core1 MPCI handler for the receive response is:<br><br>_Message_queue_MP_Process_packet()<br>case MESSAGE_QUEUE_MP_RECEIVE_RESPONSE:<br><br> the_thread = _MPCI_Process_response( the_packet_prefix );<br><br> if (the_packet->Prefix.return_code == RTEMS_SUCCESSFUL) {<br> *(size_t *) the_thread->Wait.return_argument =<br> the_packet->size;<br><br> _CORE_message_queue_Copy_buffer(<br> the_packet->Buffer.buffer,<br> the_thread->Wait.return_argument_second.mutable_object,<br> the_packet->size<br> );<br> }<br><br> _MPCI_Return_packet( the_packet_prefix );<br> break;<br><br>As far as i understand is the core 1 who frees the packet.<br>And
in case of a timeout waiting at the queue, there is no response at all
from core 0 so there's no return for the allocated packet nor the proxy.<br><br>> I don't know the MPCI code good enough. It would help if you have a<br>> self-contained test case which runs with PSIM (the PowerPC GDB built-in<br>> simulator).<br><br>Attached
to this mail is the code of the sample app that generates this
situation, the most important part is after line 186. But it's a very
simple product-consumer queue example.<br><br>We have found that this
problem has a work around by creating the message queue by the consumer.
If you do that the timeout is always in a local object and avoids the
proxy waiting and all problems related to the timeout management.</div><span> </span><span class="GroupwiseReplyHeader"><br><br>>>> Sebastian Huber <sebastian.huber@embedded-brains.de> 01/30/19 3:25 AM >>><br></span>On 29/01/2019 20:32, Andres Monteverde wrote:<br>> Hi, my name is Andres and the purpose of this mail is to ask about a <br>> situation we're dealing with and a possible solution.<br>> We are using rtems 4.10.2 in leon3 (gr712) AMP configuration with a <br>> shared memory space of 0x1000 bytes.<br>> Our system consists of two applications. One of them is the owner of a <br>> global queue and the other is the consumer with a timeout.<br>> The app running on core 0 sends a message every five seconds and the <br>> app running on core 1 receives them with a timeout of one second.<br>> After eigth timeouts, the application running in core 1 stops due an <br>> internal error.<br>><br>> Analysing the operations of the OS, we've seen that the internal error <br>> is generated by the lack of free shared memory, and it happens inside <br>> the function _MPCI_Get_packet().<br>> And we believe that the lack of free memory is because previously <br>> timed-out mpci packets are not returned.<br>> The same seems to happen with the proxys allocated in case of time <br>> out, their are allocated using _Thread_MP_Allocate_proxy() and are not <br>> returned.<br>><br>> If we perform the changes below, the test app runs indefinitely <br>> without any error.<br>> Whats your opinion about this?<br>><br>><br>> diff -r basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/rtems/src/msgmp.c <br>> original/basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/rtems/src/msgmp.c<br>> 174c174<br>> < rtems_status_code result = (rtems_status_code) <br>> _MPCI_Send_request_packet(<br>> ---<br>> > return (rtems_status_code) _MPCI_Send_request_packet(<br>> 179,184c179<br>> <<br>> < _MPCI_Return_packet(&the_packet->Prefix);<br>> <<br>> < return result;<br>> <<br>> < break;<br>> ---<br>> > break;<br><br>I don't think this is correct. If you call _MPCI_Send_request_packet(), <br>then the ownership of this packet is transferred to the implementation <br>of this function. With the shared memory driver, the packet is freed by <br>the receiver, see Shm_Free_envelope().<br><br>> diff -r <br>> basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/score/src/threadqtimeout.c <br>> original/basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/score/src/threadqtimeout.c<br>> 51d50<br>> < break;<br>> 55c54<br>> < break;<br>> ---<br>> > break;<br>> 57,61c56,58<br>> < //todo check for critical section<br><br>This is an important TODO. The code below doesn't work under all conditions.<br><br>> < the_thread->Wait.return_code = <br>> the_thread->Wait.queue->timeout_status;<br>> < _Thread_queue_Extract_with_proxy(the_thread);<br>> < _Thread_Unnest_dispatch();<br>> < break;<br>> ---<br>> > _Thread_queue_Process_timeout( the_thread );<br>> > _Thread_Unnest_dispatch();<br>> > break;<br><br>I don't know the MPCI code good enough. It would help if you have a <br>self-contained test case which runs with PSIM (the PowerPC GDB built-in <br>simulator).<br><br>-- <br>Sebastian Huber, embedded brains GmbH<br><br>Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>Phone : +49 89 189 47 41-16<br>Fax : +49 89 189 47 41-09<br>E-Mail : sebastian.huber@embedded-brains.de<br>PGP : Public key available on request.<br><br>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br><br></div></body></html>