• 状态
  • 已锁定 已锁定
  • 回复 35 回复
  • 订户 0 订户
  • 视图 2950 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] AM6442：am65-cpsw-nuss 以太网驱动程序锁定

admin
Guru**** 2557800 points
Other Parts Discussed in Thread: AM6442, SK-AM64B

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1288552/am6442-am65-cpsw-nuss-ethernet-driver-lockup

器件型号：AM6442
主题中讨论的其他器件： SK-AM64B

您好！

在运行 TI 内核6.1.46-rt13 (09.01.00.002-RT)时、我在 AM6442上观察到以下以太网问题。

发生这种情况后、 以太网通信中断、需要重新启动才能再次运行。

[2826.211565]------- [剪切此处]-------
[2826.211581] NETDEV 看门狗：eth0 (am65-cpsw-nuss):传输队列0超时
[2826.211650]警告：CPU：0 PID：11 at net/sched/sch_generic.c:525 dev_watchdog+0x254/0x260
[2826.211688] CPU: 0 PID: 11 Comm: ktimers/0 not damed 6.1.46-rt13 #1
[2826.211698]硬件名称：
[2826.211704] pstate：60000005 (nZCv daif -pan -uaO -tco -dit -ssbs BTYPE=--)
[2826.211714] PC : dev_watchdog+0x254/0x260
[2826.211725] lr : dev_watchdog+0x254/0x260
[2826.211736] sp : ff800008bb3c20
[2826.211739] x29：ff800008bb3c20 x28：ff8000085d2430 x27：ff800008bb3d30
[ 2826.211755] x26：ff00006fc23d50 x25：000000000000 x24：000000000000
[2826.211766] x23：ff8000089b8000 x22：000000000000 x21：ff000001c683a0
[2826.211778] x20：ff000001c68000 x19：ff000001c68468 x18：ffffffffffffffffffffffffffffffffffffffffffff
[ 2826.211789] x17：6f2064656d697420 x16：3020657565757120 x15：74696d736e617274
[2826.211801] x14：203a297373756e2d x13：74756f2064656d69 x12：7420302065756575
[2826.211812] x11：712074696d736e61 x10：7274203a29737375 x9：777370632d35366d
[2826.211824] x8 : ff8000089cb1f0 x7 : ff800008bb3A30 x6 : 000000000000000c
[ 2826.211836] x5 : ff00006fc23b40 x4 : 000000000000 x3 : 0000000000000027
[ 2826.211846] x2 : 000000000000 x1 : 000000000000 x0 : ff000000cd8d80
[ 2826.211858]呼叫追踪：
[ 2826.211862] DEV_WATCHDOG+0x254/0x260
[2826.21184] call_timer_fn.constprop.0+0x20/0x80
[ 2826.211891]__run_timers+0x270/0x2f0
[ 2826.211902] run_timer_softirq+0x1c/0x40
[ 2826.211913]_stext+0xf4/0x228
[ 2826.211922] run_timersd+0x60/0xc0
[ 2826.211935] smpboot_thread_fn+0x278/0x2e0
[2826.211945] kthread+0x110/0x120
[ 2826.211953] ret_from_fork+0x10/0x20
[2826.211963]----[结束追踪0000000000000000]----
[2826.211983] am65-cpsw-nuss 80000.Ethernet eth0: TxQ:0 DRV_XOFF:0 tMO:5660 dql_avay:-2 free_desc:509
[ 2831.331490] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：10780 dql_avail：-2 free_desc：509
[ 2837.219386] am65-cpsw-nuss80000.Ethernet eth0：TxQ:0 DRV_XOFF：0 tmo：16668 dql_avail：-2 free_desc：509
[ 2842.083298] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：21532 dql_avail：-2 free_desc：509
[ 2847.203202] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：26652 dql_avail：-2 free_desc：509
[ 2852.323117] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：31772 dql_avail：-2 free_desc：509
[ 2858.211011] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：37660 dql_avail：-2 free_desc：509
[ 2863.330918] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：42780 dql_avail：-2 free_desc：509
[ 2869.218815] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：48668 dql_avail：-2 free_desc：509

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

    我做了更多的调查、当在驱动器中启用接收时间戳(用于1588 PTP)时、似乎会发生这种情况。

    即、运行命令

    hwstamp_ctl -i eth0 -r 1

    确实会导致以太网驱动程序在传输几百兆字节的数据后锁定。

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

    9.0 SDK 版本中是否存在此问题？ 9.1版本是初始版本、可能存在很多问题。

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

    使用09.00.00.001-RT 进行测试、在同一测试中遇到严重故障：

    [54.633619]无法处理虚拟地址1794ecb8bfe302a7的内核分页请求
    [ 54.641564]内存中止信息：
    [ 54.644350] ESR = 0x000096000044
    [ 54.648088] EC = 0x25：DABT (当前 EL)、IL = 32位
    [ 54.65339] SET = 0、FNV = 0
    [ 54.656433] EA = 0、S1PTW = 0
    [ 54.659566] FSC = 0x04：0级转换故障
    [ 54.664431]数据中止信息：
    [ 54.667301] ISV = 0，ISS = 0x00000044
    [54.671125] CM = 0，WNR = 1
    [ 54.674083][1794ecb8bfe302A7]用户和内核地址范围之间的地址
    [54.681204] Internal error：Oops：0000000096000044 [#1] preempt_RT SMP
    [54.681216] CPU：0 PID：93 Comm：IRQ/152-8000000 not damed 6.1.26-rt8 #1
    [ 54.681225]硬件名称：
    [54.681230] pstate：60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSB BTYPE=---)
    [54.681239] PC : am65_cpsw_nuss_rx_poll + 0x150/0x390
    [54.681263] lr : am65_cpsw_nuss_rx_poll + 0x130/0x390
    [54.681271] sp : ff800009c13b80
    [54.681274] x29: ff800009c13b80 x28: 1794ecb8bfe30297 x27: ff00004dcdc4b0
    [ 54.681288] x26：ff0000022e3670 x25：0000000000000600 x24：0000000000000040
    [54.681298] x23：ff0000022e2080 x22：ff00004dc480 x21：ff00000243C000
    [54.681309] x20：ff0000022e3648 x19：000000000006 x18：000000000000
    [ 54.681319] X17：000000000000 x16：000000000000 x15：000000000000
    [ 54.681329] x14：0000000000000001 x13：0000000000000089 x12：0000000000000000
    [ 54.681339] x11：000000000000c400 x10：0000000000000038 x9：ff00000234b308
    [54.681349] x8 : ff000002c5b0b0 x7 : 000f0000cdc480 x6 : 000f0000cdcdc480
    [54.681359] x5 : ff00004dc4c0 x4 : 000f000082b05ac0 x3 : ff00004dc4c0
    [ 54.681369] x2 : 00000000000003d8 x1 : ff000002439080 x0 : ff000002439080
    [54.681380]呼叫跟踪：
    [ 54.681384] am65_cpsw_nuss_rx_poll + 0x150/0x390
    [ 54.681394]__NAPI_POLL.constprop.0+0x34/0x180
    [ 54.681406] net_rx_action+0x128/0x2c0
    [ 54.681413]_stext+0xf4/0x228
    [ 54.681423]__LOCAL_BH_ENABLE_IP+0xc0/0x130
    [ 54.681437] irq_forced_thread_fn+0x94/0xb0
    [ 54.681448] IRQ_THREADY+0x140/0x200
    [54.681455] kthread+0x110/0x120
    [ 54.681462] RET_FROM_FO叉+0x10/0x20
    [ 54.681477]代码：b90077e2 52807b02 9ba20400 f9400415 (f9000b95)
    [54.837123]--[结束跟踪000000000000]---
    [54.837129]内核严重错误-未同步:糟糕:中断中出现致命异常
    [54.848591] SMP:停止辅助 CPU
    [ 54.848615]内核偏移：已禁用
    [ 54.848618] CPU 特性：0x00,00000000004,0000400b
    [ 54.848624]内存限制：无

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

    09.00.011-RT 也失败。

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

    09.00.00.011 (不是实时)也失败。

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

    我对多个具有 ptp4l 和 HW 时间戳的 GB 运行了 iperf3测试(ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threashold=1 -m -q -p /dev/ptp0)，但没有看到此问题？ 我对调用  hwstamp_ctl -i eth0 -r 1也执行了相同的操作、但没有看到此问题。

    您能详细说明一下运行项目的总体设置是什么吗？ 例如、命令运行的序列。

    我怀疑 RT 优先级的设置可能会导致 DMA 结构的一些服务出现问题。

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

    谢谢、这有助于缩小放大器的范围。 "hwstamp_ctl -i eth0 -r 1"、"-r 1"看起来要求为每个传入数据包设置时间戳。 因此、这可能是数据因每秒高数据包流量而过载的情况。 我尝试了9.0公开发布版本和9.1候选发布版本的几种不同组合、但无法复制。 默认的 iperf3是 TCP 与最大 MTU 的所以数据包速率相对较低,我尝试 "iperf3 -c am6442.hostname -u -L100 -b100M"也创建了更大的每秒数据包速率。 我还摆弄了改变优先级的时钟(ksoftirqs 的时钟以及到 FIFO 的优先级的时钟)来看看这是否会出现。 似乎在系统中的某个时候、每个数据包的时间戳都会使系统过载、而且运行异常。 某些内容必须与默认 SDK 不同、因为我无法重现。 编译支持通常、特别是 RT 尚未通过正常版本的完整测试、只要我无法在受支持的 SDK 上重现、将范围缩小到错误就会有问题。

    为了继续、我建议了几种可能的方法：

    -是否确实要对所有接收到的数据包进行时间戳? 还是 PTP 功能。
    -运行 ptp4l 的用例是什么? 如果您使用硬件时间戳运行 ptp4l (ptp4l 的选项-H)，是否会出现问题？ 或者您是否出于其他原因运行辅助程序 hwstamp_ctl？
    -在您的打印输出上,iperf3吞吐量对于 TCP 看起来相当低,它应该达到900-950Mbit/s。 您是否并行运行其他任务？ 在不要求所有接收到的帧都有时间戳的情况下、TCP 吞吐量是多少？

     佩卡

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

    尊敬的 Pekka：

    一些评论和更新。

    *对所有传入数据包进行时间戳记是 CPSW/CPTS 硬件的唯一选择。 请参阅 am64-cpsw-nus.c 中的 am64_cpsw_nuss_hwtstamp_set。
    *是的,用例是运行 ptp4l ,但是,运行 hwstamp_ctl 会直接降低测试设置。
    * 我同意 iperf3吞吐量看起来很低,我还没有分析过,但可能是由于 -RT 内核中的线程中断处理程序。
    令人惊讶的是,运行 ipperf3 - BIDIR 始终在一个方向上提供非常低的吞吐量(~150MBits/秒),无论哪个内核正在运行。

    我之前使用非实时内核运行了相同的测试、也失败了(请参阅前面的注释)。

    我在办公室找到了 SK-AM64B 板,并加载了最新的 Yocto SDK [1]。 对于我来说、运行以下命令序列几乎会立即失败：

    root@am64xx-evm：~ cat /etc/issue
    ______ ______ __
    |_|_______|____|||
    |||_|.'|。 |。 ||____|。 ||||-|_|_|
    |___||||||||||||||||||||||||||____|||||||||||||____|||||____|||___||||||||||||||||||||||
    |________|||___|

    Arago 项目\n \l

    Arago 2023.04 \n \l

    root@am64xx-evm：~# uname -a
    Linux am64xx-evm 6.1.33-g40c32565ca #1 SMP 抢占7月6日星期四14:17:24 UTC 2023 Aarch64 Aarch64 GNU/Linux
    root@am64xx-evm：~# hwstampctl -i eth0 -r 1
    root@am64xx-evm:~# iperf3 -s
    -------------------------------------------------------
    服务器正在收听5201 (测试#1)
    -------------------------------------------------------
    接受来自10.117.68.128端口44656的连接
    [5]本地10.117.68.142端口5201连接到10.117.68.128端口44672
    [ ID]间隔传输比特率
    [5] 0.00-1.00 sec 53.9MB 452 Mbits/sec
    [5] 1.00-2.00秒0.00字节0.00位/秒
    [5] 2.00-3.00 sec 0.00字节0.00位/秒
    [5] 3.00-4.00秒0.00字节0.00位/秒
    [5] 4.00-5.00秒0.00字节0.00位/秒
    删除了一些行
    [607.074314]------- [剪切此处]-------
    [ 607.079005] NETDEV 看门狗：eth0 (am65-cpsw-nuss):传输队列0超时
    [ 607.086300]警告：CPU：1 PID：0 at net/sched/sch_generic.c:525 dev_watchdog+0x214/0x220
    [ 607.094590]模块链接如下: iptable_nat XT_masquerade nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_tables x_tables ov6
    [607.137936] CPU: 1 PID: 0 Comm: swapper/1 damed: G O 6.1.33-g40c32565ca #1
    [ 607.146360]硬件名称：德州仪器(TI) AM642 SK (DT)
    [ 607.151833] pstate：60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSB BTYPE=-)
    [607.158783] PC : DEV_WATCHDOG+0x214/0x220
    [607.162788] LR : DEV_WATCHDOG+0x214/0x220
    [607.166791] sp : ff8000000800be20
    [607.170093] x29：ff80000800be20 x28：000000000005 x27：ff800008abef10
    [607.17722] x26：ff8000092679c0 x25：ff00007fbd01a8 x24：ff800800bef0
    [ 607.184349] x23：ff800009267000 x22：000000000000 x21：ff000000c4239c
    [ 607.191476] x20：ff000000c42000 x19：ff000000c42448 x18：ffffffffffffffffffffffffffffffffffffffff
    [ 607.198603] x17：6f2064656d697420 x16：3020657565757120 x15：74696d736e617274
    [ 607.205731] x14：203a2973756e2d x13：ff800009281550 x12：00000000000005b5
    [607.212858] x11：00000000000001e7 x10：ff8000092d9550 x9：ff800009281550
    [607.219985] x8: 00000000ffefff x7: ff8000092d9550 x6: 0000000000000000
    [607.227112] x5 : ff00007fbcfb60 x4 : 000000000000 x3 : 000000000000
    [ 607.234239] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ff00000015e3C0
    [ 607.241368]呼叫跟踪：
    [ 607.243806] DEV_WATCHDOG+0x214/0x220
    [ 607.247465] call_timer_fn.constprop.0+0x24/0x80
    [ 607.252081]__run_timers.part.0+0x1f0/0x234
    [ 607.256344] run_timer_softirq+0x3c/0x7c
    [ 607.260258]_stext+0x124/0x2a4
    [ 607.263394]_____DO_SOFTIRQ+0x10/0x20
    [ 607.267049] call_on_irq_stack+0x24/0x4c
    [ 607.270964] do_softirq_own_stack+0x1c/0x30
    [ 607.275139]__IRQ_EXIT_RCU+0xcc/0xf4
    [ 607.278797] IRQ_EXIT_RCU+0x10/0x20
    [ 607.282279] el1_interrupt+0x38/0x70
    [ 607.285854] el1h_64_irq_handler+0x18/0x2C
    [ 607.289941] el1h_64_IRQ+0x64/0x68
    [ 607.293335] arch_cpu_idle+0x18/0x2C
    [ 607.296902] DEFAULT_IDLE_CALL+0x30/0x6c
    [ 607.300822] DO_IDEL+0x244/0x2c0
    [ 607.304048] CPU_STARTUP_Entry+0x24/0x30
    [ 607.307966] secondary_start_kernel+0x124/0x150
    [ 607.312491]__secondary_switch+0xb0/0xb4
    [607.316669]--[结束跟踪000000000000]---
    [ 607.321342] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：5972 dql_avail：-21 free_desc：461
    [612.962317] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：11616 dql_avail：-21 free_desc：461
    [618.082303] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：16736 dql_avail：-21 free_desc：461
    [622.946289] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：21600 dql_avail：-21 free_desc：461
    [628.066272] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：26720 dql_avail：-21 free_desc：461
    [ 633.186255] am65-cpsw-nuss 80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：31840 dql_avail：-21 free_desc：461
    [ 639.074233] am65-cpsw-nuss80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：37728 dql_avail：-21 free_desc：461
    [ 643.938217] am65-cpsw-nuss80000.Ethernet eth0：TxQ：0 DRV_XOFF：0 tmo：42592 dql_avail：-21 free_desc：461

    [1] dr-download.ti.com/.../tisdk-default-image-am64xx-evm.wic.xz

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    请参阅 am64-cpsw-nuss.c
    中的 am64_cpsw_hwtstamp_set

    抱歉、排版错误。 这是 am65-cpsw-nuss.c 中的 am65_cpsw_nuss_hwtstamp_set。

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

    尊敬的 Pekka：

    我对您的 SDK 有何不同感到困惑、我直接从发送给您的链接下载了文件。  今天我将尝试为您提出一个更易于重现的测试案例。

    是的、这个问题阻碍了我们的发展。 这一点绝对至关重要、因为它能够可靠地工作。

    总之、我目前看到在运行最新 TI 内核时出现两种不同的行为、即：
    1.以太网停止发送/接收数据包，或
    2.  am65_cpsw_nuss_rx_poll 中的内核 panic

    这些可能是单独的问题,但我希望它们都是同一个潜在的错误的症状。

    这里是一个快速分析的恐慌。 我还没有深入到足够详细的细节来准确了解目前正在发生的事情： 

    Accepted connection from 10.117.68.128, port 48592
[ 5] local 10.117.68.234 port 5201 connected to 10.117.68.128 port 48604
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 68.6 MBytes 574 Mbits/sec
[ 30.602777] Unable to handle kernel paging request at virtual address 17961a951231185b
[ 30.610723] Mem abort info:
[ 30.613507] ESR = 0x0000000096000044
[ 30.617245] EC = 0x25: DABT (current EL), IL = 32 bits
[ 30.622546] SET = 0, FnV = 0
[ 30.625591] EA = 0, S1PTW = 0
[ 30.628722] FSC = 0x04: level 0 translation fault
[ 30.633588] Data abort info:
[ 30.636458] ISV = 0, ISS = 0x00000044
[ 30.640283] CM = 0, WnR = 1
[ 30.643242] [17961a951231185b] address between user and kernel address ranges
[ 30.650364] Internal error: Oops: 0000000096000044 [#1] PREEMPT_RT SMP
[ 30.650376] CPU: 0 PID: 93 Comm: irq/152-8000000 Not tainted 6.1.46-rt13 #2
[ 30.650386] Hardware name: Relectrify Stack Controller: Relecblox-Main-Controller-SOM (DT)
[ 30.650391] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 30.650400] pc : am65_cpsw_nuss_rx_poll+0x150/0x390
[ 30.650428] lr : am65_cpsw_nuss_rx_poll+0x130/0x390
[ 30.650438] sp : ffff800009acbb80
[ 30.650441] x29: ffff800009acbb80 x28: 17961a951231184b x27: ffff00004dcd53b0
[ 30.650456] x26: ffff0000022eb670 x25: 0000000000000600 x24: 0000000000000040
[ 30.650467] x23: ffff0000022ea080 x22: ffff00004dcd5380 x21: ffff000001c70000
[ 30.650479] x20: ffff0000022eb648 x19: 0000000000000000 x18: 0000000000000000
[ 30.650490] x17: ffff80006727c000 x16: ffff800008000000 x15: ffff000002b12682
[ 30.650502] x14: 0000000000000001 x13: 00000000000001a8 x12: 0000000000000001
[ 30.650513] x11: 0000000000000040 x10: ffff800008a3b4d0 x9 : ffff800008a3b4a8
[ 30.650525] x8 : ffff80006727c000 x7 : 000f0000cdcd5380 x6 : 000f0000cdcd5380
[ 30.650536] x5 : ffff00004dcd53c0 x4 : 000f000082a9f140 x3 : ffff00004dcd53c0
[ 30.650548] x2 : 00000000000003e0 x1 : ffff000001c6d080 x0 : ffff000001c6d080
[ 30.650560] Call trace:
[ 30.650564] am65_cpsw_nuss_rx_poll+0x150/0x390
[ 30.650574] __napi_poll.constprop.0+0x34/0x180
[ 30.650588] net_rx_action+0x128/0x2c0
[ 30.650598] _stext+0xf4/0x228
[ 30.650609] __local_bh_enable_ip+0xc0/0x130
[ 30.650623] irq_forced_thread_fn+0x94/0xb0
[ 30.650635] irq_thread+0x140/0x200
[ 30.650643] kthread+0x110/0x120
[ 30.650651] ret_from_fork+0x10/0x20
[ 30.650667] Code: b90077e2 52807c02 9ba20400 f9400415 (f9000b95) 
[ 30.806403] ---[ end trace 0000000000000000 ]---
[ 30.806409] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 30.817871] SMP: stopping secondary CPUs
[ 30.817898] Kernel Offset: disabled
[ 30.817901] CPU features: 0x00000,00000004,0000400b
[ 30.817908] Memory Limit: none

0000000000458ee0 <am65_cpsw_nuss_rx_poll>:
 458ee0: a9b67bfd stp x29, x30, [sp, #-160]!
 458ee4: d5384102 mrs x2, sp_el0
 458ee8: 910003fd mov x29, sp
 458eec: a90153f3 stp x19, x20, [sp, #16]
 458ef0: 52800013 mov w19, #0x0 // #0
 458ef4: a90363f7 stp x23, x24, [sp, #48]
 458ef8: 2a0103f8 mov w24, w1
 458efc: a9046bf9 stp x25, x26, [sp, #64]
 458f00: aa0003fa mov x26, x0
 458f04: f9428040 ldr x0, [x2, #1280]
 458f08: f9004fe0 str x0, [sp, #152]
 458f0c: d2800000 mov x0, #0x0 // #0
 458f10: 9282bde2 mov x2, #0xffffffffffffea10 // #-5616
 458f14: 8b020340 add x0, x26, x2
 458f18: f9003fe0 str x0, [sp, #120]
 458f1c: 34000301 cbz w1, 458f7c <am65_cpsw_nuss_rx_poll+0x9c>
 458f20: d100a354 sub x20, x26, #0x28
 458f24: aa0003f7 mov x23, x0
 458f28: a9025bf5 stp x21, x22, [sp, #32]
 458f2c: a90573fb stp x27, x28, [sp, #80]
 458f30: 14000008 b 458f50 <am65_cpsw_nuss_rx_poll+0x70>
 458f34: f94047e1 ldr x1, [sp, #136]
 458f38: 36000421 tbz w1, #0, 458fbc <am65_cpsw_nuss_rx_poll+0xdc>
 458f3c: b94012e0 ldr w0, [x23, #16]
 458f40: 37081260 tbnz w0, #1, 45918c <am65_cpsw_nuss_rx_poll+0x2ac>
 458f44: 11000673 add w19, w19, #0x1
 458f48: 6b13031f cmp w24, w19
 458f4c: 54000fe0 b.eq 459148 <am65_cpsw_nuss_rx_poll+0x268> // b.none
 458f50: f9400e80 ldr x0, [x20, #24]
 458f54: 910223e2 add x2, sp, #0x88
 458f58: f94002f5 ldr x21, [x23]
 458f5c: 52800001 mov w1, #0x0 // #0
 458f60: a908ffff stp xzr, xzr, [sp, #136]
 458f64: 94000000 bl 351130 <k3_udma_glue_pop_rx_chn>
 458f68: 34fffe60 cbz w0, 458f34 <am65_cpsw_nuss_rx_poll+0x54>
 458f6c: 3100f41f cmn w0, #0x3d
 458f70: 540016a1 b.ne 459244 <am65_cpsw_nuss_rx_poll+0x364> // b.any
 458f74: a9425bf5 ldp x21, x22, [sp, #32]
 458f78: a94573fb ldp x27, x28, [sp, #80]
 458f7c: 6b13031f cmp w24, w19
 458f80: 5400006d b.le 458f8c <am65_cpsw_nuss_rx_poll+0xac>
 458f84: 6b18027f cmp w19, w24
 458f88: 540010cb b.lt 4591a0 <am65_cpsw_nuss_rx_poll+0x2c0> // b.tstop
 458f8c: d5384100 mrs x0, sp_el0
 458f90: f9404fe2 ldr x2, [sp, #152]
 458f94: f9428001 ldr x1, [x0, #1280]
 458f98: eb010042 subs x2, x2, x1
 458f9c: d2800001 mov x1, #0x0 // #0
 458fa0: 540014c1 b.ne 459238 <am65_cpsw_nuss_rx_poll+0x358> // b.any
 458fa4: a94363f7 ldp x23, x24, [sp, #48]
 458fa8: 2a1303e0 mov w0, w19
 458fac: a94153f3 ldp x19, x20, [sp, #16]
 458fb0: a9446bf9 ldp x25, x26, [sp, #64]
 458fb4: a8ca7bfd ldp x29, x30, [sp], #160
 458fb8: d65f03c0 ret
 458fbc: f9400a80 ldr x0, [x20, #16]
 458fc0: 94000000 bl 45e480 <k3_cppi_desc_pool_dma2virt>
 458fc4: b9400002 ldr w2, [x0]                                       *** w2 = *x0 = pkt_info0
 458fc8: aa0003f6 mov x22, x0                                        *** x22 = x0 = desc_rx
 458fcc: d2800001 mov x1, #0x0                                       *** x1 = 0
 458fd0: 37e00062 tbnz w2, #28, 458fdc <am65_cpsw_nuss_rx_poll+0xfc> *** w2 & CPPI5_INFO_HDESC_PSINFO_LOATION
 458fd4: 53167c41 lsr w1, w2, #22
 458fd8: d37e1421 ubfiz x1, x1, #2, #6                               *** x1 = (w2 & CPPI5_INFO_HDESC_PSINFO_SIZE_MASK) >> CPPI5_INFO_HDESC_PSINFO_SIZE_SHIFT
 458fdc: f9400e80 ldr x0, [x20, #24]
 458fe0: f263005f tst x2, #0x20000000
 458fe4: f94016c4 ldr x4, [x22, #40]
 458fe8: 910102c3 add x3, x22, #0x40                                 *** x3 = x22 + 64
 458fec: b94026c2 ldr w2, [x22, #36]
 458ff0: 9100c2db add x27, x22, #0x30                                *** x27 = x22 + 48
 458ff4: 9a9b1065 csel x5, x3, x27,                                  *** x5 = x3 or x27 based on x2 & CPPI5_INFO0_HDESC_EPIB_PRESENT
 458ff8: f90037e3 str x3, [sp, #104]
 458ffc: 12006c59 and w25, w2, #0xfffffff
 459000: f86168bc ldr x28, [x5, x1]                                  *** x28 = x5[x1] - load of invalid address
 459004: 910243e1 add x1, sp, #0x90
 459008: f9004be4 str x4, [sp, #144]
 45900c: 94000000 bl 351250 <k3_udma_glue_rx_cppi5_to_dma_addr>
 459010: 79401ec0 ldrh w0, [x22, #14]
 459014: f94036e1 ldr x1, [x23, #104]
 459018: 51000400 sub w0, w0, #0x1
 45901c: b94002c2 ldr w2, [x22]
 459020: b90077e2 str w2, [sp, #116]
 459024: 52807c02 mov w2, #0x3e0
 459028: 9ba20400 umaddl x0, w0, w2, x1
 45902c: f9400415 ldr x21, [x0, #8]
 459030: f9000b95 str x21, [x28, #16]                                *** x28[22] = x21 - PANIC!

x28=17961a951231184b is clearly bogus.
x5=ffff00004dcd53c0 looks ok.
Unfortunately x1 and x2 have been trampled.

    我会尽量收集更多的信息。

    帕特里克

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

    rx_poll 上面的这个最新错误在"[ 30.602777]无法处理虚拟地址17961a951231185b"的内核分页请求后看起来与我不同吗？ 您之前遇到的错误是"NETDEV 看门狗：eth0 (am65-cpsw-nuss)：传输队列0超时"。

    我仍将重点说明您的设置为何如此不同。 我想您有多个(3？) HW、SK-AM64B、Phytec SoM 的设置、您自己的 HW？ 第一个不匹配的是在任何错误出现之前的 iperf3吞吐量。 如果忽略运行"hwstamp_ctl -i eth0 -r 1"、您观察到的 iperf3吞吐量是多少？ 两台运行 ipperf3的 AM64x 设备，我希望使用默认 ipperf3 TCP 时能达到>900Mbit/s。

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

    尊敬的 Pekka：

    我在6天前的这个主题报告了恐慌。

    我对吞吐量不是特别感兴趣、但是您应该能够通过以下方式重现我的结果：
    1.用实时内核进行测试
    2.使用任何内核运行 iperf3 -- BIDIR 将在一个方向上显示较差的吞吐量(之前在这个线程中也提到过)。

    你误解了我上一篇文章中的"[ 5] 0.00-1.00 sec 68.6 MBytes 574 Mbits/sec"结果。 它之所以很低、是因为错误发生在测试之前、甚至成功运行了一秒钟。 另一个较低的结果是  运行实时内核。

    我使用三种不同的硬件设置进行了测试、包括 SK-AM64B、它们都显示相同的结果。

    时间戳对我而言似乎没有影响(误差范围内的测量)。

    您可以上报此问题、因为它会严重 影响我们的发展进度。

    帕特里克

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

    我使用三种不同的硬件设置进行了测试、包括 SK-AM64B、它们都显示相同的结果。

    [/报价]

    这是我看到严重不匹配的地方。 运行 iperf3和 hwstamp_ctl 的 SK-AM64B 不存在此问题。 在发生任何崩溃之前、您看到的 iperf3显著关闭的吞吐量。 必须有不同的配置或您正在执行的其他配置。

    我需要测试才能重现。 SD 卡 WIC 映像、hwstamp_ctl 和 iperf3在 SKs 之间以及 SK 和 ubuntu 桌面之间运行。 因为它不会、显然会创建该崩溃。

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

    一种可能是大量损坏的帧。 这适合降低 iperf3和锁定。 存在一个硬件问题、即一个非常严重损坏的帧可能会造成锁定。 我正在检查补丁以解决锁定问题、但您能否检查在未使用 hwstamp_ctl 的情况下运行 iperf3时是否有 CRC 错误？ 另一种检查方法是使用两个板和静态 IP 地址进行点对点检查。

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    这是我看到一个严重不匹配的地方。 运行 iperf3和 hwstamp_ctl 的 SK-AM64B 不存在此问题。 在发生任何崩溃之前、您看到的 iperf3显著关闭的吞吐量。 因此，必须有不同的配置或您正在执行的一些附加配置。

     如前所述、如果我运行正常(非实时)内核、吞吐量就可以(>900MBits/秒)。 只是我复制/粘贴的一项测试在不到1秒的时间内就失败了、因此统计数据显示的数据速率较低。

    运行实时内核的 速度可能是由于线程中断处理程序的原因、大约为600MBits/秒。

    在 --BIDIR 模式下运行 iperf3会在所有测试的内核上产生较差的性能。

    user4068379 说：
    我需要测试才能重现。 SD 卡 WIC 映像、hwstamp_ctl 和 iperf3在 SKs 之间以及 SK 和 ubuntu 桌面之间运行。 对你来说,它不是,显然创建了这个崩溃。

    我正在尽力提出一个易于重现的测试用例。

    user4068379 说：
    一个外部机会是大量损坏的帧。 这适合降低 iperf3和锁定。 存在一个硬件问题、即一个非常严重损坏的帧可能会造成锁定。 我正在检查补丁以解决锁定问题、但您能否检查在未使用 hwstamp_ctl 的情况下运行 iperf3时是否有 CRC 错误？ 使用两个板和静态 IP 地址进行点对点检查是另一种方法。

    听起来很有趣。 我很乐意测试您必须查看的任何补丁是否有帮助。

    这是当前锁定的板上的以太网统计信息、看起来没有错误。  

    # cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:   22034     228    0    0    0     0          0         0    22034     228    0    0    0     0       0          0
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0: 965237411  637841    0   82    0     0          0         0   963269   14480    0    0    0     0       0          0

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

    尊敬的 Pekka：

    我使用一台直接连接到 SK-AM64B 且启用了硬件时间戳的旧笔记本电脑进行测试。 同样的错误发生,它只是需要更长的时间来显现(37分钟左右的时间)。 

    root@am64xx-evm:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from fe80::56e1:adff:fe14:d67c, port 42952
[  5] local fe80::3608:e1ff:fe80:b813 port 5201 connected to fe80::56e1:adff:fe14:d67c port 42956
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   110 MBytes   923 Mbits/sec                  
[  5]   1.00-2.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   2.00-3.00   sec   110 MBytes   919 Mbits/sec                  
[  5]   3.00-4.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   4.00-5.00   sec   110 MBytes   924 Mbits/sec                  
[  5]   5.00-6.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   6.00-7.00   sec   109 MBytes   914 Mbits/sec                  
[  5]   7.00-8.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   8.00-9.00   sec   110 MBytes   921 Mbits/sec                  
...
[  5] 2246.00-2247.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2247.00-2248.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2248.00-2249.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2249.00-2250.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2250.00-2251.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2251.00-2252.00 sec   111 MBytes   928 Mbits/sec                  
[  5] 2252.00-2253.00 sec  9.69 MBytes  81.3 Mbits/sec                  
[  5] 2253.00-2254.00 sec  0.00 Bytes  0.00 bits/sec                  
[  5] 2254.00-2255.00 sec  0.00 Bytes  0.00 bits/sec                  
[  5] 2255.00-2256.00 sec  0.00 Bytes  0.00 bits/sec                  
[  5] 2256.00-2257.00 sec  0.00 Bytes  0.00 bits/sec                  
[  5] 2257.00-2258.00 sec  0.00 Bytes  0.00 bits/sec                  
[  5] 2258.00-2259.00 sec  0.00 Bytes  0.00 bits/sec

    帕特里克

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

    我仍然看到一些活动部件(打印输出和文本似乎不匹配)、让我们尝试逐个关闭它们。

    #1吞吐量

    Unknown 说：
    我使用一台直接连接到 SK-AM64B 并启用硬件时间戳的旧笔记本电脑进行测试。 发生同样的错误，只需要更长的时间(这次大约37分钟)。
    Unknown 说：
    ，如果我运行正常的(非实时)内核，吞吐量就可以(>900MBits/秒)。 只是我复制/粘贴的一个测试在不到1秒的时间内失败了,所以统计数据显示较低的数据速率。[/引号]

    这是一个具有静态 IP 地址的点对点以太网连接？ 这次是否使用 RT 图像运行？ 那么 https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-InmvA50mCw/09.00.00.03/tisdk-default-image-am64xx-evm.wic.xz ？ 我看到>900Mbit/s 开箱即用、 AM64x 上具有 iperf3 -s 和 iperf3 -c 或者像剪切粘贴一样的桌面上进行开发？ 但是、您之前的文章讨论了与 RT 相关的问题、您看到了~600Mbit/s？

    在某些版本上、根据您如何更改优先级、我还会看到~600Mbit/s。 对于 TCP 测试，运行类似 chrt 9 iperf3 -s 的程序，然后使用 RT 达到>900Mbit/s。 对于 TCP 来说，测试应用程序运行的优先级似乎高于 ksoftirq 的关键字。

    #2使用-- BIDIR

    Unknown 说：
    在 --BIDIR 模式下运行 iperf3会在所有测试的内核上产生较差的性能。

    如果您在客户端运行-- BIDIR ,上面的打印输出与我期望的情况不符? 如果我运行 iperf3 -c -- BIDIR 我看到一个额外的列,标题[角色]和 RX-S 在运行 iperf3 -s 的设备上?  

    #3损坏的帧

    Unknown 说：
    此处是电路板上当前已锁定的以太网统计信息，看起来没有错误。  [/报价]

    因此可能不是错误的数据包。  

    #4可能的其他事情可以尝试

    这不是真正的误解、而只是看看它是否有助于您继续。 我假设 hwstamp_ctl 的使用仅是一个综合测试来帮助重现问题、而您的真实应用则是另一回事？ ksoftirqd 线程已经尝试以提升的优先级运行了它们。 在负载系统中、管理这些资源有助于保持网络性能、


    PS aux | grep ksoftirq
    #种子每个内核中断处理程序的线程 ID ,在我的例子13和27
    chrt -f -p 10 13
    chrt -f -p 10 27

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

    尊敬的 Pekka：

     我发现重现此问题的另一种方法是在 iperf 运行时拔下并插入以太网电缆。 执行此操作10到20次后、以太网驱动程序将锁定。

    user4068379 说：

    #1吞吐量

    Patrick Oppenlander 说：
    我使用一台直接连接到 SK-AM64B 且启用了硬件时间戳的旧笔记本电脑进行测试。 同样的错误发生,它只是需要更长的时间来显现(37分钟左右的时间)。
    Patrick Oppenlander 说：
    如果我运行正常(非实时)内核、吞吐量就可以(>900MBits/秒)。 只是我复制/粘贴的一项测试在不到1秒的时间内就失败了、因此统计数据显示的数据速率较低。

    这是一个具有静态 IP 地址的点对点以太网连接？ 这次是否使用 RT 图像运行？ 那么 https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-InmvA50mCw/09.00.00.03/tisdk-default-image-am64xx-evm.wic.xz ？ 我看到>900Mbit/s 开箱即用、 AM64x 上具有 iperf3 -s 和 iperf3 -c 或者像剪切粘贴一样的桌面上进行开发？ 但是、您之前的文章讨论了与 RT 相关的问题、您看到了~600Mbit/s？

    在某些版本上、根据您如何更改优先级、我还会看到~600Mbit/s。 对于 TCP 测试，运行类似 chrt 9 iperf3 -s 的程序，然后使用 RT 达到>900Mbit/s。 对于 TCP 来说，测试应用程序运行的优先级似乎高于 ksoftirq 的关键字。

    [/报价]

    我需要澄清一点、我们对吞吐量不存在任何担忧。 这是一个分散了内核的问题,无论是 panic 或 以太网流量停止.

    回答您的问题：
    是的,这是一个点对点连接。
    * 该测试运行的是您链接的确切"WIC"文件。
    *是的,使用实时内核时,您会发现非实时内核的速度会降低~600MBit/s 而不是~900MBit/s。

    我没有更改任何线程优先级。

    user4068379 说：

    #2使用-- BIDIR

    Patrick Oppenlander 说：
    在 --BIDIR 模式下运行 iperf3会在所有测试的内核上产生较差的性能。

    如果您在客户端运行-- BIDIR ,上面的打印输出与我期望的情况不符? 如果我运行 iperf3 -c -- BIDIR 我看到一个额外的列,标题[角色]和 RX-S 在运行 iperf3 -s 的设备上?  

    [/报价]

    我只是指出,如果你有兴趣做通量测试,你可能会发现一些更有趣的结果运行在-- BIDIR 模式。

    user4068379 说：

    #4可能的其他事情可以尝试

    这不是真正的误解、而只是看看它是否有助于您继续。 我假设 hwstamp_ctl 的使用仅是一个综合测试来帮助重现问题、而您的真实应用则是另一回事？ ksoftirqd 线程已经尝试以提升的优先级运行了它们。 在负载系统中、管理这些资源有助于保持网络性能、

    [/报价]

    是的、我使用 hwstamp_ctl  配置以太网驱动程序、以快速重现问题。 我们的实际应用需要在现场可靠运行数月甚至数年。 我们非常关切稳定问题。

    我尚未调整任何线程优先级、因为我在此阶段不关心性能。

    帕特里克

    [/quote]
    [/quote][/quote]
  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：

    我需要澄清一点、我们对吞吐量不存在任何担忧。 这是一个分散了内核的问题,无论是 panic 或 以太网流量停止.

    回答您的问题：
    是的,这是一个点对点连接。
    * 该测试运行的是您链接的确切"WIC"文件。
    *是的,使用实时内核时,您会发现非实时内核的速度会降低~600MBit/s 而不是~900MBit/s。

    我没有更改任何线程优先级。

    [/报价]

    我知道您不关心吞吐量。 我要问的一点是、您的设置中有什么不同、具有9.0默认 RT 映像、而且据称完全相同的命令行为明显不同。 因此必须有其他一些变量、或者吞吐量应该相同。 由于出现错误、大量丢弃的帧便是这方面的一个示例。

    Unknown 说：
    我只是指出,如果你有兴趣进行吞吐量测试,在--BIDIR 模式下运行时,你可能会发现一些更有趣的结果。

    好的,所以没有什么可做的-- BIDIR。 无需继续。

    Unknown 说：
    是的，我使用 hwstamp_ctl  配置以太网驱动程序以快速重现问题。 我们的实际应用需要在现场可靠运行数月甚至数年。 稳定是我们非常关注的问题。[/引述]

    时间戳有一种变通方法、它删除了时间戳所有帧的选项。 我们仅支持为 IEEE1588设置时间戳的方法、并使用较旧的基于 FIFO 的方法、而不是描述符中的时间戳。 这是为了在存在大量损坏帧时保持稳定性。 因此、hwstamp_ctl 所有帧都是要避免的、它将被删除。

    Unknown 说：
    另一种 重现问题的方法是在 iperf 运行时拔下和插入以太网电缆。 执行此操作10到20次后，以太网驱动程序将锁定。

    这会指向损坏的帧。 您是否在此拔下/插拔序列中看到大量错误(ethtool -S eth0 | grep err)？ 没有错误的"cat /proc/net/dev "以外的所有内容都将与损坏的帧匹配、然后使用时间戳标记所有帧。 我知道您有3种类型的硬件(自有、SK、PHYTEC)、您是否有关于直接相互连接的嵌入式电路板的问题？

    仅使用 IEEE1588具有时间戳的所有帧时间戳问题权变措施对软件使用了完全不同的逻辑和传递机制、它不仅是随机的权变措施、还避免了底层损坏的存储器访问。

     佩卡

    [/quote][/quote]
  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    我要讨论的是，您的设置中存在一些不同，使用9.0默认 RT 映像，而且可能完全相同的命令行为明显不同。 因此必须有其他一些变量、或者吞吐量应该相同。 大量丢弃的帧,因为错误会是这种情况的一个例子。[/引号]

    下次(明天)在办公室时、我将重复测试并报告结果。

    我刚刚意识到"正常"和"RT"图像的文件名是完全相同的(tisdk-default-image-am64xx-evm.wic.xz)、所以现在我怀疑自己到底在运行哪个图像。

    user4068379 说：
    好了,所以与--BIDIR 无关。 无需继续。

    我认为这完全值得从性能的角度进行单独调查。

    user4068379 说：
    时间戳有一个变通办法，该方法将删除所有帧的时间戳选项。 我们仅支持为 IEEE1588设置时间戳的方法、并使用较旧的基于 FIFO 的方法、而不是描述符中的时间戳。 这是为了在存在大量损坏帧时保持稳定性。 因此 hwstamp_ctl 所有帧都是要避免的,它将被删除。

    此修复是否有 ETA？ 我认为这可能是导致 该问题的原因、您可能是对的 (见下文)。

    user4068379 说：
    这将指向损坏的帧。 您是否在此拔下/插拔序列中看到大量错误(ethtool -S eth0 | grep err)？ 没有错误的"cat /proc/net/dev "以外的所有内容都将与损坏的帧匹配、然后使用时间戳标记所有帧。 我知道您有3种类型的硬件(自有、SK、PHYTEC)、您是否存在直接相互连接的嵌入式电路板的问题？

    我今天正在远程工作、因此不能更改硬件设置、明天我会再次尝试插/拔序列、但是目前有一个电路板连接到我们的公司网络、我可以使用它进行测试。 这是 ethtool 和/proc/net/dev 统计数据。 ethtool 显示了一些错误、但/proc/net/dev 显示为0、因此我认为/proc/net/dev 的统计数据之前误导了我们。 

    # ethtool -S eth0 |grep err
     p0_rx_crc_errors: 0
     p0_ale_overrun_drop: 0
     p0_ale_len_err_drop: 0
     p0_tx_mem_protect_err: 0
     rx_crc_errors: 0
     rx_align_code_errors: 1
     ale_overrun_drop: 0
     tx_deferred_frames: 0
     rx_ipg_error: 0
     tx_carrier_sense_errors: 0
     ale_len_err_drop: 0
     iet_rx_assembly_err: 0
     iet_rx_smd_err: 29
     tx_mem_protect_err: 0
# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:     576       8    0    0    0     0          0         0      576       8    0    0    0     0       0          0
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0: 74756498   53812    0 1047    0     0          0         0    99199    1484    0    0    0     0       0          0

    user4068379 说：
    仅使用 IEEE1588帧时间戳的所有帧时间戳问题权变措施对 SW 使用完全不同的逻辑和传递机制。这不仅是随机权变措施，而且避免了底层损坏的内存访问。

    我非常渴望测试这一点！ 您能在补丁 可用时立即授予我访问权限吗？

    谢谢。

    帕特里克

    [/quote]
  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    "RT"图像完全相同(tisdk-default-image-am64xx-evm.wic.xz)

    我和大家都对此感到痛苦、不幸的命名。 我经常会弄错哪一个与这些相关的错误。  最好的方法是 在测试之前运行 uname -a、然后将粘贴复制到日志中。

    Unknown 说：
    我非常热衷于测试此内容！ 您能否在补丁 可用时立即授予我对补丁的访问权限。

    我试着给你拿一个补丁,它是回退到一个旧的 PTP 机制。 为了显示此错误，需要严重的 EMI 或帧损坏，因此以太网 MAC 级别会看到某种模式(与 TSN 功能抢占/IET/802.3br 有关)。 因此、发送损坏的帧或有意的 IET 碎片可能会导致这种情况。 你上一篇文章中的统计数据 " iet_rx_smd_err: 29"指向这个问题,29帧看起来像 IET ,但其余的不匹配。 当然、我们不应该锁定、但这一数量的错误表明您正在运行的 LAN 存在严重的质量问题。 我从未在现场网络中看到过这种损坏帧的问题、只有测试人员能够生成前导码中有错误 L1字段的数据包。

    如果您想要手动关闭时间戳、则为  TRM 中寄存器12.2.1.6.3.2 CPSW_CPTS_CONTROL_REG 寄存器中的字段 TTAMP_EN。  使用例如 devmem2将0写入地址0803 D004h 处的位3。

    在正常以太网网络中、使用高质量电缆获得带前导码的帧、而造成锁定的方式有误的情况确实很少见。 ethtool 计数器 iet_rx_smd_err 不能为零、因此在几分钟甚至几小时内都无法观察到。

    勘误表尚未包含在 AM64x 版本中，但问题与 https://www.ti.com/lit/pdf/sprz488中的问题相同 ： i2401—CPSW：主机时间戳导致 CPSW 端口锁定。 如前面所述、PTP 中的权变措施是使用选择性时间戳。

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    我将尝试为您获取一个补丁，它即将回退到 PTP 的旧机制。 [/报价]

    谢谢！

    user4068379 说：
    如果您想手动关闭时间戳，则是  TRM 中寄存器12.2.1.6.3.2 CPSW_CPTS_CONTROL_REG 寄存器中的 TSTARP_EN 字段。  使用例如 devmem2将0写入地址0803 D004h 处的位3。

    好的、我对 TRM 的理解是、禁用所有硬件时间戳、正确吗？

    清除该位可以解决 锁定问题、但 很显然、我不能   像这样继续开发我们的 PTP 应用。

    user4068379 说：
    PTP 中的变通办法是使用我之前所说的选择性时间戳。

    这仍然是硬件时间戳吗？

    帕特里克

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

    我首先要确认的是,您的工作环境中有很多 EMI 噪声,很多错误,导致以太网前导码帧开始定界符损坏,这就暴露了硬件问题( https://www.ti.com/lit/pdf/sprz488 : i2401—CPSW: 主机时间戳导致 CPSW 端口锁定)。 这就是为什么我一直在问吞吐量是否大幅下降、这将是 LAN 质量不佳或大量 EMI 噪声的另一个副作用。 在一些 AM64x 器件的隔离网络中、提供高质量的电缆是我的参考设计。 如果存在大量损坏的帧、您将看到许多其他副作用。

    Unknown 说：
    清除该位可解决 锁定问题，但 很显然，我无法   像这样继续开发 PTP 应用程序。

    是否正在运行 linuxptp/ptp4l？ 之类的设置。 在开发 PTP 用例时、什么是网络拓扑和硬件、我不会在具有错误帧的环境中这么做。

    Unknown 说：
    Pekka VARiS 说：
    如前面所述、PTP 中的权变措施是使用选择性时间戳。

    这仍然是硬件时间戳吗？

    [/报价]

    可以。 获取时间戳的位置不变。 只是传递到 SW 的机制是不同的(不是在每个数据包描述符中、而是在 FIFO 中、仅适用于 IEEE1588数据包)。

    Unknown 说：
    Pekka VARiS 说：
    我试着给你拿一个补丁,它是回退到一个旧的 PTP 机制。

    谢谢！

    [/报价]

    旧版器件的 CPSW 驱动程序、如 AM335x、它是：drivers/net/Ethernet/ti/cpsw.c 使用 CPTS FIFO 事件实现了 RX 时间戳、因此可以用作参考、不会按原样使用。 函数：
    CPTS_RX_TIMESTAMP()
    在 drivers/net/Ethernet/ti/CPTs.c 中实现了这种方法。
    实施链接： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/cpts.c?h=ti-linux-6.1.y#n505 

    Unknown 说：
    好了，我对 TRM 的理解是禁用了所有硬件时间戳，这是正确的吗？
    [/quote]

    可以。 此测试的重点是验证您是否确实遇到了此问题。

     佩卡

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

    谢谢。 这看起来很清楚正在发生大量损坏的帧( iet_rx_smd_err：386)。 这似乎也是我不复制它的原因。 我已通过硬件设计确认统计信息  Rx_Bottom_fifo_Drop (Ethtool -S 也会打印此内容)或 iet_Rx_SMD_err  不为零这种锁定可能发生。

    短期发展、假设您正在进行软件开发或评估、因为您不在嵌入式环境中、而是在企业网络中？ 我建议继续在 LAN 中进行开发、在这些测试中、您不会看到您关心时间准确度的错误。 我们使用各种 AM6x 器件的小型网络(大部分时间是3-4)测试 PTP、其中一些器件连接为交换机。 我不认为您的交换机应该导致错误(可能是电缆？)、我检查了适用于我的 Linux 桌面和我们的企业网络的 ehtool -S、我没有看到任何错误。 所以您仍会惊讶于在您的案例中看到很多错误。

    您正在使用的交换机似乎非常典型的企业级交换机、它们没有任何 IEEE1588功能、因此使用硬件时间戳无论如何都浪费了精度、因为通过交换机的跳频会产生多微秒的抖动？ 对于已部署的系统和带硬件时间戳的 PTP、我假设您计划使用支持 IEEE1588的开关？  

    我看不到修复程序或补丁程序返回到选择性时间戳的时间表。 我假设我们可以在9.2版本中获得它、因此可能在几个月内会在 CI/CD 中获得。

     佩卡

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

    尊敬的 Pekka：

    user4068379 说：
    我认为您的交换机不应该导致错误(电缆可能吗？)

    我尝试了多个全新的电缆和两个不同的 TL-SG3428X 交换机。 当 SK-AM64B 连接到  TL-SG3428X (两个不同的开关)时、我们会看到这些错误。

    我怀疑 AM64和交换机之间存在一些兼容性问题、因为没有其他 连接到交换机的器件报告错误。 我们还可以通过 Phytec 板和自己的板看到这些错误。

    user4068379 说：
    我看不到修复程序或修补程序返回到选择性时间戳的时间表。 我假设我们可以在9.2版本中获得它，所以可能在几个月内就可以在 CI/CD 中获得它。

    感谢您的更新、

    帕特里克

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    Pekka VARiS 说：
    我认为您的交换机不会导致错误(可能是电缆？)

    我尝试了多个全新的电缆和两个不同的 TL-SG3428X 交换机。 当 SK-AM64B 连接到  TL-SG3428X (两个不同的开关)时、我们会看到这些错误。

    我怀疑 AM64和交换机之间存在一些兼容性问题、因为没有其他 连接到交换机的器件报告错误。 我们还可以通过 Phytec 板和自己的板看到这些错误。

    [/报价]

    您可以使用 profishark https://www.profitap.com/profishark-1g/ 或其他测试仪来查看从 TL-SG3428X 发出的帧吗？ 或者、如果您没有分接头、请尝试其他器件、并检查它们从 TL-SG3428X 接收的帧中是否存在任何以太网级别错误？ 除了这种锁定,这只存在这个特定的损坏的帧,缩小什么破坏的帧将是我认为你需要理解的东西,否则它可能会有进一步的副作用。 我们已运行 SK-AM64B 、例如、运行 https://www.keysight.com/us/en/products/network-test/network-test-hardware/novus-one-plus-l2-7-fixed-chassis.html 而不观察错误。

    TCP 的吞吐量大幅下降可能是帧损坏的副作用。

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

    尊敬的 Pekka：

    user4068379 说：
    您可以使用 profishark https://www.profitap.com/profishark-1g/ 或其他测试程序来查看来自 TL-SG3428X 的帧吗？ [/报价]

    遗憾的是、我们没有以太网分析器。 我已经使用端口镜像查看了数据以进行采集、但这并没有显示任何问题。

    我不确定那种类型的测试仪会 显示多少——使用同一个端口连接到另一个设备没有显示错误，据我所知，这种类型的测试仪通常背靠背安装两个 PHY，这很可能会掩盖我们看到的问题。

    我怀疑 交换机和 AM64之间存在配置或电气问题导致损坏。

    帕特里克

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    我看了使用端口镜像进行捕获的数据，但没有显示任何问题。

    端口镜像不会镜像损坏的帧,但我认为 tcpdump -n -e -i eth0和原始捕获可能会给你带来什么。 记录 AM64x 发送的流量和开关  TL-SG3428X 发送的流量、然后在 Wireshark 中打开。

    Unknown 说：
    我不确定这种类型的测试仪会 显示多少——使用连接到另一台设备的同一端口没有显示错误，据我所知，这些类型的测试仪通常背靠背安装两个 PHY，这可能会掩盖我们看到的问题。

    Profishark 等真正的网络分析器将捕获所有流量、包括 L1 (IEEE802.3)级别的损坏帧、而不是从 PHY 到 MAC 到另一个 PHY 的流量、因此您可以准确地看到这些帧是如何损坏的。

    Unknown 说：
    我怀疑 交换机和 AM64之间存在配置或电气问题导致了损坏。

    我同意、我怀疑这一点类似、但在特定于 TL-SG3428X 和/或 AM64x 的 xMII 或 PHY 级别。 我不认为这是 MAC 级作为前导码和类似的 L1正在损坏。

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    Profishark 等真正的网络分析器将捕获所有流量，包括 L1 (IEEE802.3)级别的损坏帧，而不是从 PHY 到 MAC 到另一个 PHY，因此您可以确切地看到帧是如何损坏的。

    如果您 可以 借用一台分析仪进行测试 、我很乐意执行 捕获以尝试调试硬件。

    即使我们这样做、也无法解决 AM64x 硬件锁定的问题。 您是否有关于 AM64x 硬件锁定修复的任何新闻？

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    如果您 可以 借给我一台分析仪进行测试  ，我很乐意执行捕获以尝试调试硬件。

    您如何测试终端系统中的 LAN 级别问题？ Profishark 可能需要1-2美元(我不知道您的位置是什么)、如果您至少要构建嵌入式网络产品、我建议您购买。 但也有许多其他网络流量分析器和测试仪。

    另外、如何在纳秒级测试 PTP 精度？ 直到低于毫秒级别时、才需要硬件时间戳。

    Unknown 说：
    您是否有关于 AM64x 硬件锁定的修复消息？

    用于使用 FIFO 方法而非所有帧的更新时间戳不会出现在下周发布的9.1 SDK 版本中。 因此、它可能是9.2版本、即1H24、在 CI/CD 早期版本中。

      佩卡

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    您如何在终端系统中测试局域网级别问题？ Profishark 可能需要1-2美元(我不知道您的位置是什么)、如果您至少要构建嵌入式网络产品、我建议您购买。 但也有许多其他网络流量分析器和测试仪。

    当然，但很难让 Bean 计数器在这方面花费1美元，因为：
    1. 我们已经确认了  TI 的芯片里有一个错误
    2. TI 将 提供修复。
    3.一旦 TI 提供了修复来停止硬件锁定、这将不会对我们的产品造成问题。

    在最终 产品配置中、有  一个单独的内部控制网络和一个面向客户的以太网端口、用于云连接。 我们不太可能在内部看到数据包损坏(当然、这种情况始终可能是由于电气噪声)、但我们无法控制客户连接到其端口的内容。

    我 个人想深入了解 测试 配置中导致数据包损坏的原因、但这与我们实际试图实现的目标相差甚远、因此 花时间休息并非特别有用。

    user4068379 说：
    如何在纳秒级别测试 PTP 精度？ 在低于毫秒级别之前，您不需要硬件时间戳。

    系统运行一个需要在节点之间同步的20us 控制环路。

    user4068379 说：
    使用 fio 方法而不是所有帧的更新时间戳不会出现在下周发布的9.1 SDK 版本中。 因此、它可能是9.2版本、即1H24、早期的 CI/CD 版本。

    感谢您的更新、

    帕特里克

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Unknown 说：
    在最终 产品配置中，有  一个单独的内部控制网络和一个面向客户的以太网端口用于云连接。 我们不可能在内部看到数据包损坏(当然、这通常是由于电气噪音)、但我们无法控制客户连接到其端口的内容。

    好的、我将关闭此代码、因为锁定很明显、需要修复、可能在 TI 9.2 SDK 中提供、在 https://software-dl.ti.com/cicd-report/linux/index.html?section=platform&platform=am64xx 中提供。 我假设您不会在云端口上运行 PTP。

    我有点惊讶,也许10%(?)  以太网帧损坏不能作为一种理由来尝试找出损坏的来源并尝试修复或对此做出反应。 以太网所需的误码率通常在10^-9的范围内或几个数量级更好、我认为确切值是特定于物理接口的。 鉴于我根据日志看到的错误数量、它不再符合以太网规范、其他将中断的内容也将是未知的。

     佩卡

  • 0
    TI__Guru**** 2557800 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    user4068379 说：
    我有点惊讶,也许10%(?) [/报价]

    远远不到10%。 上面的一个日志显示了53812数据包中的30个错误、因此对于、运行误差 约为 0.06%。 不过、这仍然是令人无法接受的糟糕。

    user4068379 说：
    不是试图找出腐败来源并尝试修复或应对腐败的理由。

    我们的测试很明显、 TL-SG3428X 开关不太可能出现故障。 还有 许多 其他器件连接到该开关。 它们都不会报告任何交换机端口上的任何错误。 只有 SK-AM64B 和其他基于 AM64x 的硬件存在问题。

    所有器件的共同点是问题端存在 DP83867 + AM64x。

    帕特里克

     

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

    下面是1588时间戳的补丁、该补丁仅用于1588帧而不是所有帧。 它应该在9.2 SDK 中。

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_net_2D00_ethernet_2D00_ti_2D00_am65_2D00_cpsw_2D00_cpts_2D00_Add_2D00_workaround_2D00_for_2D00_er.patch

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

    谢谢、我来试一下！