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.

[参考译文] Linux/AM5728:UDP 流量会导致 CPSW 驱动程序故障

Guru**** 2611705 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/648737/linux-am5728-udp-traffic-leads-to-cpsw-driver-failure

器件型号:AM5728

工具/软件:Linux

您好!

我遇到一个问题、在某些情况下会观察到看门狗超时、稍后所有连接都会丢失。 这是在 定制板上使用内核4.4.3.32-rt41。  

此主题似乎 是相同的问题、但不清楚问题是如何解决的。

以下是在短时间内出现的内核跟踪、具有足够的 UDP 流量:

[670.004814]------ [在此处剪切]-----
[670.012508]警告:CPU:0 PID:4 AT [已删除]/kernel-source/net/sched/sch_generic.c:306 DEV_安全 装置+0x26c/0x278 ()
[670.041482] NETDEV 安全装置:ETH1 (cpsw):发送队列0超时
[670.050634]链接的模块:pm4351 (O) suliter_pcie (O) 0 (cupdf)[670.050634] CPU:cf cf (cf
) 0 (ccs_cf):0 ccs_cryptd cf (cf (cf)[670.064 o 4.4.3.32-rt41 #1
[670.063592]硬件名称:通用 DRA74X (平展设备树)
[670.063596]背板:
[670.063613][ ](dump_backtrace)从[ ](show_stack+0x18/0x1c)
[670.063622] r7:c0563098 r6:200f0013 r5:00000000 r4:c099c604
[ 670.063634][ ](show_stack)从[ ](dump_stack+0x8c/0xa0)
[670.063645][ ](dump_stack)从[ ](warn_slespath_common+0x88/b8)
[670.063653] r7:c0563098 R6:00000132 R5:00000009 R4:ee4a1e00
[670.063662][ ](warn_slowpath_common)、来自[ ](warn_slespath_fmt+0x38/0x40)
[670.063671] r8:edf68e00 r7:00000001 r6:c0968580 r5:ee512000 r4:c08bc250
[670.063680][ ](warn_slowpath_fmt)、来自[ ](DEV_WATCHDOGER+0x26c/0x278)
[670.063685] R3:ee512000 R2:c08bc250
[670.0636688] R4:00000000
[670.063696][ ](DEV_Watchdog)从[ ](call_timer_fn.constprop.3+0x30/0xa0)
[670.063706] R10:c0562e2c R9:ee512000 R8:c0305d4 r7:c0562e2c R6:00000000 R5:00000000
[670.063709] R4:ffe000
[670.063715] ](call_timer_fn.constprop.3)、来自[ ](run_timer_softirq+0x19c/0x228)
[670.063722] r7:00000200 R6:00000000 R5:00000000 R4:eed30580
[ 670.063730][ ](run_timer_softirq)、来自[ ](do_curry_softirqs+0x1b8/0x254)
[670.063739] r10:00000001 r9:ee4a1ed0 r8:00000000 r7:04208140 r6:ee4a0000 r5:00000004
[670.063742] r4:c09612b0
[670.063748] ](do _curry_softirq)、从[ ](run_ksoftirqd+0x34/0x64)
[670.063757] R10:00000000 R9:00000000 R8:ffe000 r7:c0980c70 R6:00000001 R5:ee443c40
[670.06378] R4:ffe000
[670.063768][ ](run_ksoftirqd)、来自[ ](smpboot_thread_fn+0x164/0x2b8)
[670.063772] R5:ee443c40 R4:ee4a0000
[670.063780][ ](smpboot_thread_fn)、来自[ ](kthread+0xe4/0xFC)
[670.063790] R10:00000000 R9:00000000 R8:00000000 r7:c0054504 R6:ee443c40 R5:ee443cc0
[670.063793] R4:00000000 R3:ee4915c0
[670.063801][ ](kthread)、来自[ ](RET_FAND_FANK+0x14/0x24)
[670.063808] r7:00000000 R6:00000000 R5:c0051040 R4:ee443cc0
[670.063810]--[结束跟踪000000000002 ]-- 

一些其他信息:

通过/proc/softirqs、我们可以看到 TX 和 RX 计数器之间缺乏对称性。 我本来希望它们接近1:1

~# cat /proc/softirqs
CPU0 CPU1
您好: 0 2.
计时器: 142416. 142438.
NET_TX: 526. 4.
Net_RX:2380381 20020.
块: 0 0
BLOCK_IOPOLL: 0 0
TASKLET: 2. 31.
计划: 140379 77417
HRTIMER: 407. 194.
RCU: 0 0 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    请遵循此检查清单并将结果发布在以下位置: processors.wiki.ti.com/.../5x_CPSW
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我已将请求的信息附加到此邮件中。  

    另一个有趣的注意事项是、在看到有关看门狗故障的初始内核跟踪后、更改套接字缓冲区大小(使其更大)会导致所有网络流量发生故障所需的时间更长。

    以下 sysctl 设置有所帮助、但几个小时后、我发现电路板无法通过以太网进行通信。

    net.core.netdev_max_backlog = 65536
    net.core.optmem_max = 65536
    net.core.somaxconn = 16384
    net.core.rmem_default = 1048576
    net.core.wmem_default = 1048576
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.ipv1.udp_rmem_min = 16384
    net.ipv4.udp_wmem_min = 16384

    e2e.ti.com/.../ti_5F00_triage1.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    感谢您发布鉴别分类结果。

    内核的来源、您能解释一下它的来源吗? 它来自 TI SDK、主线吗? uname -a 命令中的版本与 TI 发布的版本不同。

    当接口接收到极高的数据速率并且内核网络堆栈在尝试发送数据包时超时时、就会发生看门狗超时。 该消息由堆栈生成、并向驱动程序发出复位命令。 该消息仅打印一次、但看门狗可能再次发生、随后导致驱动器复位、而不显示控制台指示。

    设置 sysctl 值将有助于处理 UDP 丢包。 所连接的 ethtool -S 命令的结果中有两个字段、显示了帧丢弃的开始和 DMA 溢出。 这些是丢包、是由内部 RX FIFO 满和 CPDMA 不在 RX 描述符范围内引起的。

    请描述您正在执行的应用以及您的应用所需的要求吗?

    当连接停止时、什么会停止? ifconfig 或 ethtool -S 上的 RX 和 TX 八位位组计数是否不增加? ping 是否不能用于收发? 控制台输出上是否有任何显示"链路断开"?

    此致、
    Schuyler
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Schuyler、感谢您的深入见解!

    内核来自 TI SDK (PROCESSOR-SDK-LINUXD-RT-03.02.00)、但进行了一些修改(与 cpsw 以太网无关)。

    我想添加一些 printk 来查看驱动程序是否正在持续复位可能会很有用。

    如果内部 RX FIFO 已满、CPDMA 正在用尽描述符、那么它应该能够在丢失一些数据包后恢复、对吧?

    我观察到的情况会导致完全和永久的交通损失。 Ping 不起作用、计数器停止增加。 另一个有趣的现象是、在运行命令[netstat -c --udp -an](在连接丢失之前)时、您可以看到发送和接收队列增长并缩小。 发生损失时、通常其中一个队列中有一个值与该点相同。 这似乎表示不再为队列提供服务。

    哦、从不会有一条链路断开消息。

    我想知道我上面发布的与其他论坛帖子的链接是否提供了任何线索。 或许需要添加更多 DMA 通道?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    e2e.ti.com/.../5873.0001_2D00_net_2D00_ethernet_2D00_ti_2D00_cpdma_2D00_am437x_2D00_allow_2D00_descs_2D00_to_2D00_be_2D00_plase.txtHi、

    在处理高带宽网络使用时、您可能会遇到几个 SDK 之前遇到的问题。 附加的修补程序更改了 CPDMA 寄存器的访问方式。 由于您开始查看的代码库已经进行了一些更改、因此可能需要手动应用此补丁。 该补丁对它在另一个处理器上修复的问题进行了良好的描述、这是 AM335x 的后续操作。

    关于驱动程序重置、这是内核在遇到网络看门狗时所做的事情。 重置 的目的是看起来不那么像、但不会影响吞吐量。 如果您查看 Wireshark、则会在接口重置时看到流量骤降。

    此致、

    Schuyler

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们尝试了该补丁、但遗憾的是它未解决问题。 我会声称我们的应用带宽不是很高。 当出现看门狗跟踪时、可能为300kbps。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    这是一个低数据速率。 在该位速率下看到看门狗超时、会发现其他问题。 由于这是 RT 内核、其他哪些应用程序正在运行?

    此外、为了让您了解可能出现的延迟回复、我们即将进入假期休息、我将在1月的第一周返回
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Schuyler、您好、

    我们基本上只需使用 busybox shell 和测试应用程序就能重现此问题。 测试应用程序仅用于重现此问题(更快)。 它所做的就是打开套接字并调用 sendto (...) 小数据包(200字节有效载荷)。

    问题似乎仅与 TX 有关。 如果我们从另一台机器向它发送大量数据包、我们会看到 RX 计数增加、但问题永远不会出现。

    在我们的调查中,似乎在某些时候 CPDMA 通道被填满,我们可以看到 cpdma_chan_submit()返回错误,因为它无法从其池中分配 DMA 描述符。 CPsw 驱动程序似乎从未在其任一 MAC 上恢复。

    请在 此处查看内核源代码。

    你怎么看?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    虽然错误是可能的、但应丢弃数据包、驱动程序应恢复。 当我看到超时时时时、TX 是通常超时的通道。

    是否可以附加您正在使用的应用程序代码? 驱动器应从 Rx 解耗尽条件中恢复。

    此致、
    Schuyler
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们还希望驱动程序能够恢复。 如果单独保留、它将永远不会发生。

    运行以下命令将恢复网络一段时间、但它会以相同的方式快速再次失败:

    IP 链路将 eth0设置为 down

    IP 链路设置 eth0 up

    我附上了用于重现问题的超简单代码。 我知道忽略 send()函数的返回值是不正确的,但这只是为了重现最坏的情况。 用户空间不能断开网络连接。

    e2e.ti.com/.../pktgen.c

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    查看您看到的问题后、我们希望您尝试两个补丁、第一个是与看门狗超时相关的链接、另一个是建议的补丁。

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75514b6654859e0130b512396dc964d2a9e84967

    e2e.ti.com/.../2438.0001_2D00_net_2D00_ethernet_2D00_cpsw_2D00_add_2D00_check_2D00_for_2D00_rgmii_2D00_phy_2D00_interface_2D00_patch.txt

    此致、

    Schuyler

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    第一个补丁很有趣。 它确实具有避免总流量损失的效果。 现在、当问题发生时、没有传输数据包的临时平静状态、然后当调用超时函数时、一组数据包会传出。 那么在下一个超时(1s 周期)发生之前没有任何内容。 这是对情况的改进、但根本原因仍然未知。 也许我们已经接近尾声了。

    在我自己的调查中、我怀疑启动和停止 netdev 队列有问题。 似乎没有人在调用 WAKE_QUEUE()…… 我的理解是、这应该通过以下方式来实现:

    TX_POLL ()-> CHAN_PROCESS()-> CHAN_FREE ()-> TX_handler ()...


    至于第二个修补程序;它似乎没有效果。 我们主要使用100 (或1000)的链路速度。