• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 264 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.

MCU-PLUS-SDK-AM263X: TSN ydbi readrelsem increments endlessly

Hudson Ayers
Prodigy 30 points
Part Number: MCU-PLUS-SDK-AM263X

Tool/software:

On our system we are using the TSN gPTP stack on an AM2634-based board. We have observed that the yang_db readrelsem increments seemingly endlessly, ending up with an extremely high count. Specifically, the semaphore getting posted here: https://github.com/TexasInstruments/enet-tsn-stack/blob/1b105e2adbd5bdec0e93c7c0712b7a22d5bc05d3/tsn_uniconf/yangs/yang_db_access.c#L1737 .

Is this by design? It seems like that semaphore might just be used to protect against the case of a second db read beginning before a previous read has finished, and this is expected behavior in the case that we never have consecutive reads in that way?

  • 0
    TI__Genius 16502 points

    Hi Hudson, 

    I'll look into it and get back.

    Regards,

    Shaunak

  • 0
    TI__Genius 16502 points

    Hi Hudson,

    Hudson Ayers said:
    We have observed that the yang_db readrelsem increments seemingly endlessly, ending up with an extremely high count

    While I am trying to get more information from the networking core team internally, do you mind sharing if this is causing any issues as of now? For example the semaphore counter wrapping around or overflowing because of incrementing constantly and breaking your application? Or causing inconsistent DB reads simultaneously? 

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    We have not observed any issues in practice yet, but we are concerned about the potential for the counter to overflow or for the loop that clears the counter to not be long enough

  • 0 in reply to Hudson Ayers
    TI__Genius 16502 points

    Hi Hudson, please find the reply from our networking core team attached below:

    "I was able to reproduce the issue. 

    The sem counter is increasing without reducing. 

     

    There is only case which is reducing the sem counter to zero, is in https://github.com/TexasInstruments/enet-tsn-stack/blob/1b105e2adbd5bdec0e93c7c0712b7a22d5bc05d3/tsn_uniconf/yangs/yang_db_access.c#L1752, but it's happened only if there is another Read (from another thread) is coming while the current Read is reading DB.

     

    However, currently, there is no impact for now. 

    Since the normal case (No Read action comes while current Read is in progress), the sem counter will be kept at the MAX counter and stay there without issue.

    In special case (another Read action comes while the current Read is in progress), the sem counter will be reduced from MAX to zero and wait (with timeout) until the current Read is finished.

    Anyway, we are considering, and we might update the code a little bit, to avoid increasing this SEM counter endlessly. We will let you know the update as soon as possible.

     "

    Hudson, I would like to know if this is a blocking issue for you as of now? The team is anyways planning on updating the logic avoid the SEM increasing endlessly.

    Thanks and Regards.
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    Thanks Shaunak. This is not currently a blocking issue -- we are happy to pull in the updated logic once the team delivers it in a future release. Appreciate you looking into this.