• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 105 subscribers
  • Views 1512 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C6678 QMSS Descriptors Recovery

Goo
Prodigy 70 points

1. Everyone who knows KeyStone I Navigator module, Descriptors detailed release and recovery process, not found in the manual.

2. Environment: C6678 or C6670 platform, The Network driver of the bare machine.

    Data sending process description:  CPU pop out of a Descriptors in the sending complete queue,After the Descriptors is filled,Push Descriptors into the send queue,Start PktDMA,PktDMA will send the data in the queue to transport to the net peripherals, the net peripherals send data out.When Descriptors is pushed into the sending queue，Program through the TXGOODFRAMES register to determine the success of the transmission.The number of Descriptors is 32.

   Problem description:  When the data sent successfully completed,The number of Descriptors in the send complete queue is less than 32.It indicates that the descriptor is not successful recovery in time.This will cause the next time when data is sent，the number of Descriptors popped from the sending complete queue is less than the number of Descriptors required for this send.This phenomenon has the occasional,Most of the time after the completion of the transmission, Descriptors are normally recycled,Sometimes the above situation occurs.

  Debug program fragment:

Thanks!

  • 0
    TI__Guru* 81335 points

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com). Please read all the links below my signature.

    We will get back to you on the above query shortly. Thank you for your patience.

    Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

  • 0
    TI__Guru**** 161600 points
    Hi,

    Which SDK (also sepcify sdk version) are you using?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Genius 12805 points
    Hi Goo, let's see if I understand you

    When you say not successful recovery you mean that the descriptors are not back in the Free Descriptor Queue (FDQ)?

    If so I have two comments to make and see how to progress from there

    In the past we saw issues when there was non-synchronization between the external peripheral (that is, the Ethernet cable to the switch) and the initialization of the QMSS and the PA. What happened was that the PA started to fill descriptors and try to send them out before the destination queue was opened.

    Ir seems like this is not your case because you see issues with transmit descriptors (am I right?) and not receive descriptors but it may be a similar situation.

    So my second comment is the following -
    If descriptors are "lost" they must be in some queues. My guess is that they are in "error queues", so look and see what other queues aside of the FDQ have the "missing" descriptors. If you see these queues, see how they were defined. It may give you a hint what is wrong.

    Does it make sense to you? Report back to the forum

    Best Regards

    Ran
  • 0 in reply to ran35366
    Intellectual 660 points

    Hi Ran,

    Sorry, for interrupting, but cloud you please elaborate more on this issue,

    "In the past we saw issues when there was non-synchronization between the external peripheral (that is, the Ethernet cable to the switch) and the initialization of the QMSS and the PA. What happened was that the PA started to fill descriptors and try to send them out before the destination queue was opened."

    or direct me to corresponding forum thread?

    Because in my case when the Ethernet cable plugged into DSP in the heavy loaded network, I observe this error "Timeout waiting for reply from PA to Pa_addMac command" and I can't start the program. But if i will plug off the Ethernet cable the program starting with no problem and working correctly. So every time I change something and reload the binary to DSP I have to plug off the cable and plug it in back, it's really annoying. The situation you described can explain such behavior. It would be a great help if the problem you talking about is my case. Thank you in advance.

    Best Regards,

    Pavlo!

  • 0 in reply to Pavlo Sergiienko
    TI__Genius 12805 points

    Pavlol

     I worked on the problem with a peer who is on vacation.  He may remember better than I so when he returns he may update the details.

    The issue was about descriptors. The original question was how many descriptors are needed. Turns out that the hardware interface used to start working before the QMSS drivers and queues were functional so descriptors were sent but were not processed or something like this. Not sure about the exact details.

    Please look at     https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/367192

    and other postings that associate descriptors with EMAC or PA and see if this help

    Best Regards

    Ran

  • 0 in reply to ran35366
    Intellectual 660 points

    Ran,

    Thank you for the information, but unfortunately i didn't find a solution to my problem. Although I get some new clues. Also your colleague mentioned that descriptor that we take to send command to PA from gTxFreeQHnd queue is not the same descriptor we are waiting to se as response from PA in the gPaCfgCmdRespQHnd queue. Before  thought that this is the same one. My first question is From what queue PA pops a descriptor to send it to respond queue? 

    Giving all above mentioned I suppose that when the Ethernet cable is plugged in I get this "Timeout waiting for reply from PA to Pa_addMac command"  error because PA can't get the free descriptor and process just time out. But when the is no Ethernet cable attached, there is no network loading and PA can successfully retrieve the free descriptor and send a response. Is it make any sense to you?

    Best Regards,

    Pavlo!

  • 0 in reply to Pavlo Sergiienko
    TI__Mastermind 30365 points
    Pavlo,
    Could you please take a look at this thread that was previously worked on?
    e2e.ti.com/.../1510869

    I believe it discusses symptoms similar to what you are mentioning. Perhaps it would shed some light on your problem.

    Lali
  • 0 in reply to Lalindra Jayatilleke
    Intellectual 660 points

    Hi Lali,

    Thank you for your post I have found a lot of useful information, at least now I have some understanding of what is happening. Unfortunately the mentioned solutions in the thread didn't help, although I removed all SerDes init functions in the Platform_init and in the .gel file.  Is there any information about what solutions were made to "disconnect" the cable by software, because in Chris case helped the combination of that two methods. Hope there is some info about that.

    Best regards, Pavlo!