• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1298 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/AM5726: MessageQ remote recipient going offline

Tim Dylla
Expert 1070 points

Part Number: AM5726

Tool/software: TI-RTOS

Hi,

  we're using MessageQ with virtio/Rpmsg as transport layer in order to communicate between an ARM/Linux world application and a TI/RTOS firmware running on a DSP core. Everything works just fine but we have to make the application more robust against possible failure.

On a sane linux application shutdown we officially disconnect with a 'disconnect' message to which the DSP firmware reacts by resetting its messageq sw module.

But if the linux application is killed or it runs into a segfault, there is no way to send a final disconnect message. This leads to following question:

How can we detect the recipients disconnect programmatically on DSP side?

Right now it isn't detected at all and the next MessageQ_put call takes around 200ms to return. Very unpleasant for a realtime DSP application....

Do you have any suggestions?

Best,

            Tim

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 43296 points
    Tim,

    If you specify the 'timeout' value instead of 'MessageQ_FOREVER' in the messageQ API, would it help detect the remote end failure?

    Int MessageQ_get(MessageQ_Handle handle,
    MessageQ_Msg *msg,
    UInt timeout)

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Expert 1070 points
    Garrett,

    we do this right now and it's no sufficient workaround.
    We have kind of a keepalive message that the linux application sends every n ms - unfortunately n is not a constant and can add up to a second (that's why the DSP takes care of the realtime part). On DSP side the messageQ_get is called with a timeout that is around 2sec and if the call returns by indicating a timeout we 'close' the remote connection (means: we delete all information about a remote queue - no messages will be sent anymore). But this is way too late and MessageQ_get doesn't seem to return when the remote Queue is closed. How could it? It's a n:1 connection and 'get' is called on the local queue, not on the remote.

    From a theoretical point of view I would assume that only the MessageQ_put call could sufficiently detect a closed remote queue because even if there would be a way to 'ask' the system if it's still open, the 'asking' and the MessageQ_put call would have to be atomic to be safe.

    Best,

    Tim
  • 0 in reply to Tim Dylla
    Expert 1070 points
    Hi Garrett,

    anything new on this topic? I'm still stuck.

    Best,

    Tim
  • 0 in reply to Tim Dylla
    TI__Mastermind 43296 points
    Tim,

    >> MessageQ_get doesn't seem to return when the remote Queue is closed.
    Do you mean the timeout doesn't take effect when the remote queue is closed? or just the timeout latency is too high? What is your time requirement for the detection of host disconnect?

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Expert 1070 points
    MessageQ_get returns happily after the timeout but does not return an error other than the timeout. Especially it does not reflect the state of the remote Queues. Please read my message from Oct 6, 2017 3:36 AM again, I think I stated clearly why IMHO the issue can't be resolved by calling MessageQ_get.
  • 0 in reply to Tim Dylla
    TI__Mastermind 43296 points

    Tim,

    Thought you have keepalive message being sent every n ms, then MessageQ_get returning due to timeout should indicate remote queue failure. MessageQ_put may not help as both MessageQ_get and MessageQ_put are through the same rpmsg transport. Although MessageQ_get receives message from local queue, its message is actually from the remote end by MessageQ_put. If your application requires a hard real time for the notification of remote recipient going offline, you may have to develop a custom mailbox based handshaking mechanism, see discussion here:

    Regards,

    Garrett

  • 0 in reply to Garrett Ding
    Expert 1070 points

    Garrett,

      thanks for the link, I think I have to rethink my RTOS Task model. It should be possible to do the sending always in the same Task as the receiving - that would be the necessary prerequisite to make the MessageQ_get timeout ceasing communication with ARM side.

    Beside that I wonder what makes the RPMSG Layer take so long to return from a MessageQ_put call? Is there a way to have control over this timespan, maybe via any kind of configuration?

    Best,

             Tim

  • 0 in reply to Tim Dylla
    TI__Mastermind 43296 points
    Tim,

    200ms MessageQ_put return while remote is disconnected is really longer than expected. I don't think there is option to control the time span. MessageQ has queues prioritized (normal, high, urgent) but should not help in this case. You may run Execution Graph tool to identify if rpmsg really takes such long time or some other tasks interfere with it.

    Regards,
    Garrett