• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 157 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.

TDA4VH-Q1: NETDEV WATCHDOG: CPU: 4: transmit queue 2 timed out 508184 ms

hongyao.jin
Expert 1180 points
Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Tool/software:

TDA4VH customer board

SDK 11.0 linux+freertos

When our multi-cam program started streaming, after a few minutes, we noticed that the network connection was lost and we couldn't ping the board anymore.

Serial port error log is as follows:

root@tda4vh-dt2vh:~#
root@tda4vh-dt2vh:~#
root@tda4vh-dt2vh:~# [   85.024143] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 5116 ms
[   85.036016] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 5124 dql_avail:-256 free_desc:504
[   90.048243] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 10140 ms
[   90.060196] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 10148 dql_avail:-256 free_desc:504
[   95.172357] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 15264 ms
[   95.184299] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 15272 dql_avail:-256 free_desc:504
[  100.032465] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 20124 ms
[  100.044445] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 20136 dql_avail:-256 free_desc:504
[  105.152471] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 25244 ms
[  105.164417] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 25252 dql_avail:-256 free_desc:504
[  110.272349] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: NETDEV WATCHDOG: CPU: 2: transmit queue 2 timed out 30364 ms
[  110.284304] ti_cpsw_proxy_client virtio1.ti.ethfw.ethdevice.-1.34 eth0: txq:2 DRV_XOFF: 0 tmo: 30372 dql_avail:-256 free_desc:504

  • 0
    TI__Mastermind 38390 points

    Hi,

    Does the multi-cam program use ethernet interfaces to stream or to send large data?

    This happens when one of the queue becomes unresponsive.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Expert 1180 points

    hi

    The data we transmit and receive through our network is not large. According to the SDK documentation, we can see that cpsw_proxy_client accomplishes the transmission and reception of network data by moving shared memory data through DMA.

    Before the problem arises, our board will run some models on the C7X. It is expected that DMA will also be involved in the transfer of shared memory.

    So, can we doubt that there might be a conflict between the DMA transfer in C7x and the cpsw_proxy_client, or whether this indirectly led to the occurrence of this problem in cpsw_proxy_client?

  • 0 in reply to Tanmay Patil
    Expert 1180 points

    hi

    After our model was running, it seemed that the load on C7x was quite high. Could this be related to the cpsw_proxy_client issue?

    And is it related to the insufficient power supply? Because of the high power consumption of C7x..

  • 0 in reply to hongyao.jin
    TI__Mastermind 38390 points

    Hi,

    hongyao.jin said:
    And is it related to the insufficient power supply? Because of the high power consumption of C7x..

    This should not be the case. The issue comes from the fact that there is no completion interrupt for cpsw tx packets which is causing the tx queue to lock up. I am trying to replicate this with EVM. So this could be a DMA issue.

    It would be helpful if you have a set of steps I can follow to get to this state with out-of-box SDK.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Expert 1180 points

    hi

    We have found that changing numTxCh from 2 to 1 might increase the probability of timeout occurrence. You can give it a try.

  • 0 in reply to Tanmay Patil
    Expert 1180 points

    hi

    In our program, both VPAC1 and VPAC2's MSCs are used simultaneously. We found that when we replaced the MSC node of VPAC2 with that of VPAC1, the problem disappeared.

    So it seems that the use of MSC with VPAC2 would cause this problem. What could be the possible reasons for this issue?Are there any differences between VPAC1 and VPAC2?

  • 0 in reply to hongyao.jin
    TI__Mastermind 38390 points

    Hi,

    I am checking this with our experts on how VPAC ties into this. Please expect a response early next week.

    Regards,
    Tanmay