MPCI not returning memory

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Jan 30 06:25:32 UTC 2019


On 29/01/2019 20:32, Andres Monteverde wrote:
> Hi, my name is Andres and the purpose of this mail is to ask about a 
> situation we're dealing with and a possible solution.
> We are using rtems 4.10.2 in leon3 (gr712) AMP configuration with a 
> shared memory space of 0x1000 bytes.
> Our system consists of two applications. One of them is the owner of a 
> global queue and the other is the consumer with a timeout.
> The app running on core 0 sends a message every five seconds and the 
> app running on core 1 receives them with a timeout of one second.
> After eigth timeouts, the application running in core 1 stops due an 
> internal error.
>
> Analysing the operations of the OS, we've seen that the internal error 
> is generated by the lack of free shared memory, and it happens inside 
> the function _MPCI_Get_packet().
> And we believe that the lack of free memory is because previously 
> timed-out mpci packets are not returned.
> The same seems to happen with the proxys allocated in case of time 
> out, their are allocated using _Thread_MP_Allocate_proxy() and are not 
> returned.
>
> If we perform the changes below, the test app runs indefinitely 
> without any error.
> Whats your opinion about this?
>
>
> diff -r basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/rtems/src/msgmp.c 
> original/basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/rtems/src/msgmp.c
> 174c174
> <       rtems_status_code result = (rtems_status_code) 
> _MPCI_Send_request_packet(
> ---
> >       return (rtems_status_code) _MPCI_Send_request_packet(
> 179,184c179
> <
> <       _MPCI_Return_packet(&the_packet->Prefix);
> <
> <       return result;
> <
> <        break;
> ---
> >       break;

I don't think this is correct. If you call _MPCI_Send_request_packet(), 
then the ownership of this packet is transferred to the implementation 
of this function. With the shared memory driver, the packet is freed by 
the receiver, see Shm_Free_envelope().

> diff -r 
> basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/score/src/threadqtimeout.c 
> original/basicsw_el1618_rtems_4.10/rtems_4.10/cpukit/score/src/threadqtimeout.c
> 51d50
> <         break;
> 55c54
> <         break;
> ---
> >       break;
> 57,61c56,58
> <         //todo check for critical section

This is an important TODO. The code below doesn't work under all conditions.

> <      the_thread->Wait.return_code = 
> the_thread->Wait.queue->timeout_status;
> <         _Thread_queue_Extract_with_proxy(the_thread);
> <         _Thread_Unnest_dispatch();
> <         break;
> ---
> >       _Thread_queue_Process_timeout( the_thread );
> >       _Thread_Unnest_dispatch();
> >       break;

I don't know the MPCI code good enough. It would help if you have a 
self-contained test case which runs with PSIM (the PowerPC GDB built-in 
simulator).

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the users mailing list