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:以太网无法接收 IPv6 邻居请求数据包(平均每 50 次重新引导 1 次)

Guru**** 2574685 points
Other Parts Discussed in Thread: AM6442

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1562983/am6442-ethernet-fails-to-receive-ipv6-neighbour-solicitation-packets-1-out-of-50-reboots-on-average

器件型号:AM6442


工具/软件:

基本信息:

phyCORE-AM64x 模块

TI SDK 版本:10.01.10

Linux 内核版本:6.12.43

问题:

当我们执行重新引导循环测试时、设备会持续自行软重新引导、我们最终会进入以太网无法接收传入的 IPv6 邻居请求数据包的状态。 症状是外部设备无法 ping 设备的 IPv6 链路本地地址。

我们知道以太网硬件正在接收多播邻居请求数据包、因为我们每秒 ping 一次器件、并且可以看到网络数据包计数器 (ethtool -S、ip -s link) 随 ping 一起递增。 但是、我们无法看到这些带有 tcpdump 的数据包。 数据包在某处丢弃。

出现以下操作来解决该问题:

*软重启。

*从 AM6442 器件到外部世界的 Ping。

*从外部世界 ping IPv6 链路本地地址 FF02::1.

*启用 allmulti 或混杂标志,默认情况下在以太网代码中进行硬编码(如果我们等到出现问题,然后尝试启用混杂模式,则问题不会自行修复)。

命令 ip maddr show dev eth0 将显示所有正确的条目。

不调用驱动程序的数据包接收功能。

请就如何调试此问题向我们提供建议。

了解如何找出数据包丢弃的位置会很有用。

学习如何查询以太网硬件的多播表会很有用。

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

    您好 Dimitrios、

    1.您是否可以共享显示如何运行此“重启循环“测试的日志、出现问题的日志、 ethtool -S、ip -s 链接日志,其中您可以看到“多播邻居请求数据包、不含这些数据包的 tcpdump 以及用于解决问题的操作序列的任何命令?  

    2.此外、您是否能够在 AM64x EVM 上重现同样的问题?  

    3.我假设您使用的是 CPSW 以太网?

    4.这种“重启循环“测试导致问题的时间大约是多久?  

    -道林

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

    尊敬的 Daolin:

    1.测试执行以下操作。

      a) 使用确定性 IPv6 链路本地地址通过 TCP 套接字连接到器件。 此设备是 TCP 服务器、PC 是 TCP 客户端。

      b) 从器件中提取一些数据。

      C) 然后使用 linux reboot 命令重新引导

      d) 从 a 中重复)

    1-100 次重新引导后、会随机出现问题。

    出现问题时、PC 正在发送邻居请求、但设备未收到请求。


    如果我执行以下操作之一、问题就会消失:
    a) 从 PC 到设备执行 IPv6 链路本地广播 (FF02::1)

    b) 从设备 ping PC

    c) 对以太网驱动程序进行硬编码、通过将这条线路添加到函数 emac_ndo_set_rx_mode_work 中来始终将其置于混杂模式:
    nDEV->flags |=(IFF_PROMISC | IFF_ALLMUTI);

    我附加了一个包含各种日志和统计信息的 zip 文件。 它还包含 2 个数据包捕获功能。 一个来自器件侧、另一个来自 PC 侧。

    您将从数据包跟踪中看到以下内容。 我启动从 PC 到设备的 ping、最初它不工作、因为设备未收到邻居请求。 然后我对 FF02::1 执行广播 ping 操作、问题就会得到解决。

    e2e.ti.com/.../12sep.zip

    2.我没有尝试过 EVM。

    3、我们没有使用 CPSW。 我们正在使用 icssg-prueth。

    4.在 50 次重新引导中、大约有 1 次出现问题。

    您能否向我指出说明如何从  icssg-prueth 硬件中获取信息和统计信息的文档?
    我特别想访问统计信息和组播过滤设置。

    我还想了解如何更新到最新的 icssg-prueth 驱动程序和固件。

    另一个问题:

    在每 1000 次重新引导时、我们还会看到另一个频率约为 1 的问题。
    在这种情况下、设备无法传输任何以太网流量。
    设备认为它正在传输、但对等计算机没有接收到任何内容。
    该设备通过普通以太网电缆直接连接到对等 PC、因此数据包丢失不是以太网交换机丢弃数据包造成的。
    我会就此提出一个单独的问题、但只需告知您这不是唯一的问题、这 2 个问题可能是相关的。

    此致、

    Dimitrios Siganos

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

    另一个有趣的症状是、虽然未收到 IPv6 邻居请求、但同时 IPv4 流量运行正常。

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

    尊敬的 Dimitrios:

    [引述 userid=“638880" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1562983/am6442-ethernet-fails-to-receive-ipv6-neighbor-solicitation-packets-1-out-of-50-reboots-on-average/6024660

    您能否向我指出说明如何从  icssg-prueth 硬件中获取信息和统计信息的文档?
    我特别想访问统计信息和组播过滤设置。

    我还想了解如何更新到最新的 icssg-prueth 驱动程序和固件。

    [/报价]

    有关 ethtool -i 的统计数据的大多数信息可以在 AM64x TRM 中找到。 例如、在第 6.4.14.12 节中、PRU_MII_G_RT_MII_G_RT 寄存器。 同样、您可以通过检查 TRM 的 PRU_ICSSG 寄存器部分(例如第 6.4 节可编程实时单元和工业通信子系统 — 千兆位)、找到有关多播设置和统计信息的更多信息。

    就最新的 icssg-prueth Linux 驱动程序而言、您可以在以下网址找到该驱动程序: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/icssg?h=ti-linux-6.12.y-cicd 

    据我所知、icssg-prueth 固件源代码已公开可供共享、但我可以在内部再次检查。

    设备认为它正在传输、但对等计算机没有收到任何内容。
    该设备通过普通以太网电缆直接连接到对等 PC、因此数据包丢失不是以太网交换机丢弃数据包造成的。
    我将就此提出一个单独的问题、但只需让您知道这不是唯一的问题、这 2 个问题可能是相关的。

    感谢您提出此问题并制作一个单独的线程。 我还想分享以下几点、本应用手册中的一些技巧在调试通信问题时可能会很有帮助、比如您所面临的问题: https://www.ti.com/lit/an/spradj8/spradj8.pdf 。需要注意的主要问题是、这些技巧并不特定于会导致通信问题的重复重新启动情况。

    如果您有其他问题、敬请告知。

    -道林

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

    尊敬的 Daolin:

    我怀疑、当问题发生时、icssg 硬件中的多播过滤器表设置不正确。

    为了帮助我诊断此问题、我希望能够打印硬件 Rx 过滤器表的内容以进行调试。

    数据表似乎非常复杂。 您是否有任何用于打印 Rx 过滤器表的代码示例或其他一些帮助?

    Rx 滤波器表存储在哪些寄存器或 RAM 中的位置?

    症状的快速总结:

    * IPv6 多播邻居发现数据包由硬件接收(我可以看到数据包计数随着发送的数据而增加)

    *数据包从不显示在 tcpdump 中,也没有证据表明它沿着网络堆栈传播。

    *我怀疑它可能被 Rx 滤波器表丢弃。 如何进行调试?

    此致、

    Dimitrios Siganos

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

    尊敬的 Dimitrios:

    这些问题非常深入地探究了 PRU-ICSSG 以太网、因此我请一位同事帮助您更好地解决这个问题。

    如果您没有收到星期四的回复、请 Ping 此主题。

    -道林

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

    您好 Dimitrios、

    挖掘 PRU 以太网源代码、分析多播滤波器等并不简单。 在朝着这个方向走得太远之前、让我们退一步。

    您是否已验证以太网接口是否正确出现?  我假设您在 9 月份附加的“dmesg"日志“日志是失败的情况? 我看到了在“工作中“案例中不会看到的错误。

    您的引导日志:

    // PRU cores are "available"
    [    0.664430] remoteproc remoteproc5: 30034000.pru is available
    [    0.665702] remoteproc remoteproc6: 30004000.rtu is available
    [    0.667236] remoteproc remoteproc7: 3000a000.txpru is available
    [    0.668533] remoteproc remoteproc8: 30038000.pru is available
    [    0.669764] remoteproc remoteproc9: 30006000.rtu is available
    [    0.671008] remoteproc remoteproc10: 3000c000.txpru is available
    [    0.680485] remoteproc remoteproc11: 300b4000.pru is available
    [    0.681795] remoteproc remoteproc12: 30084000.rtu is available
    [    0.683223] remoteproc remoteproc13: 3008a000.txpru is available
    [    0.684501] remoteproc remoteproc14: 300b8000.pru is available
    [    0.685783] remoteproc remoteproc15: 30086000.rtu is available
    [    0.687067] remoteproc remoteproc16: 3008c000.txpru is available
    
    // Ethernet driver fails to connect to the PHY
    // is this still there in a "working" case?
    [    0.803866] icssg-prueth icssg1-eth: couldn't get ti,pa-stats syscon regmap
    [    0.805630] icssg-prueth icssg1-eth: registering netdevs
    [    0.806797] icssg-prueth icssg1-eth: couldn't connect to phy ethernet-phy@1
    [    0.806830] icssg-prueth icssg1-eth: can't connect to MII0 PHY, error --19 (deferring)
    ...
    [    0.953334] icssg-prueth icssg1-eth: couldn't get ti,pa-stats syscon regmap
    [    0.954923] icssg-prueth icssg1-eth: registering netdevs
    [    0.984880] Marvell 88E1510 300b2400.mdio:01: attached PHY driver (mii_bus:phy_addr=300b2400.mdio:01, irq=POLL)
    [    1.012880] Marvell 88E1510 300b2400.mdio:00: attached PHY driver (mii_bus:phy_addr=300b2400.mdio:00, irq=POLL)
    [    1.012940] icssg-prueth icssg1-eth: TI PRU ethernet driver initialized: dual EMAC mode
    
    // 35 seconds before PRU firmware gets loaded?
    [   38.008245] remoteproc remoteproc11: powering up 300b4000.pru
    [   38.018716] remoteproc remoteproc11: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 39636
    [   38.018778] remoteproc remoteproc11: unsupported resource 5
    [   38.018812] remoteproc remoteproc11: remote processor 300b4000.pru is now up
    [   38.018871] remoteproc remoteproc12: powering up 30084000.rtu
    [   38.020542] remoteproc remoteproc12: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30444
    [   38.020621] remoteproc remoteproc12: remote processor 30084000.rtu is now up
    [   38.020677] remoteproc remoteproc13: powering up 3008a000.txpru
    [   38.022640] remoteproc remoteproc13: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 39080
    [   38.022715] remoteproc remoteproc13: remote processor 3008a000.txpru is now up
    [   38.022775] remoteproc remoteproc14: powering up 300b8000.pru
    [   38.028907] remoteproc remoteproc14: Booting fw image ti-pruss/am65x-sr2-pru1-prueth-fw.elf, size 39796
    [   38.028973] remoteproc remoteproc14: unsupported resource 5
    [   38.029009] remoteproc remoteproc14: remote processor 300b8000.pru is now up
    [   38.029072] remoteproc remoteproc15: powering up 30086000.rtu
    [   38.031183] remoteproc remoteproc15: Booting fw image ti-pruss/am65x-sr2-rtu1-prueth-fw.elf, size 29680
    [   38.031256] remoteproc remoteproc15: remote processor 30086000.rtu is now up
    [   38.031312] remoteproc remoteproc16: powering up 3008c000.txpru
    [   38.033439] remoteproc remoteproc16: Booting fw image ti-pruss/am65x-sr2-txpru1-prueth-fw.elf, size 37568
    [   38.033525] remoteproc remoteproc16: remote processor 3008c000.txpru is now up
    [   38.046642] bond0: (slave eth1): Enslaving as a backup interface with a down link
    [   38.102690] bond0: (slave eth0): Enslaving as a backup interface with a down link
    [   42.180093] icssg-prueth icssg1-eth eth0: Link is Up - 1Gbps/Full - flow control off
    [   42.211225] bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex
    [   42.211288] bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
    [   42.211337] bond0: active interface up!
    

    “正常“引导时看到的内容(在 Linux SDK 11.0 上捕获):

    // PRU cores are "available", do not get loaded yet
    [   10.794199] remoteproc remoteproc5: 3000a000.txpru is available
    [   10.801411] remoteproc remoteproc6: 3000c000.txpru is available
    [   10.812508] remoteproc remoteproc7: 3008a000.txpru is available
    [   10.819554] remoteproc remoteproc8: 3008c000.txpru is available
    [   11.868769] remoteproc remoteproc9: 30034000.pru is available
    [   11.893564] remoteproc remoteproc10: 30004000.rtu is available
    [   11.910451] remoteproc remoteproc11: 30038000.pru is available
    [   11.925763] remoteproc remoteproc12: 30006000.rtu is available
    [   11.941685] remoteproc remoteproc13: 300b8000.pru is available
    [   11.996745] remoteproc remoteproc14: 30086000.rtu is available
    [   12.015655] remoteproc remoteproc15: 300b4000.pru is available
    [   12.031660] remoteproc remoteproc16: 30084000.rtu is available
    
    [   12.124975] TI DP83869 300b2400.mdio:0f: attached PHY driver (mii_bus:phy_addr=300b2400.mdio:0f, irq=POLL)
    
    // Ethernet driver is initialized
    [   12.125023] icssg-prueth icssg1-eth: TI PRU ethernet driver initialized: single EMAC mode
    
    // Ethernet driver loads firmware into the PRU cores
    [   13.953231] remoteproc remoteproc15: powering up 300b4000.pru
    [   13.968112] remoteproc remoteproc15: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 39636
    [   13.968158] remoteproc remoteproc15: unsupported resource 5
    [   13.968189] remoteproc remoteproc15: remote processor 300b4000.pru is now up
    [   13.968240] remoteproc remoteproc16: powering up 30084000.rtu
    [   13.990456] remoteproc remoteproc16: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30444
    [   13.990519] remoteproc remoteproc16: remote processor 30084000.rtu is now up
    [   13.990566] remoteproc remoteproc7: powering up 3008a000.txpru
    [   13.999081] remoteproc remoteproc7: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 39188
    [   13.999146] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
    [   13.999199] remoteproc remoteproc13: powering up 300b8000.pru
    [   14.001787] remoteproc remoteproc13: Booting fw image ti-pruss/am65x-sr2-pru1-prueth-fw.elf, size 39796
    [   14.001830] remoteproc remoteproc13: unsupported resource 5
    [   14.001861] remoteproc remoteproc13: remote processor 300b8000.pru is now up
    [   14.001906] remoteproc remoteproc14: powering up 30086000.rtu
    [   14.006587] remoteproc remoteproc14: Booting fw image ti-pruss/am65x-sr2-rtu1-prueth-fw.elf, size 29680
    [   14.006641] remoteproc remoteproc14: remote processor 30086000.rtu is now up
    [   14.006691] remoteproc remoteproc8: powering up 3008c000.txpru
    [   14.016455] remoteproc remoteproc8: Booting fw image ti-pruss/am65x-sr2-txpru1-prueth-fw.elf, size 37676
    [   14.016522] remoteproc remoteproc8: remote processor 3008c000.txpru is now up
    
    // link is up
    [   17.125868] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

    我很想看到正常工作的引导日志和不正常工作的引导日志之间存在差异。

    此致、

    Nick

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

    您好、Nick、

    如果我在出现问题的接口上发送传出的 IPv6 以太网流量或从地址 FF02::1 上的另一台计算机执行广播 ping、则我假设接口是打开的、因为 IPv4 在出现问题时工作正常、而且问题会自行修复。

    工作案例中的 dmesg 日志与非工作案例中的 dmesg 日志不相同。

    从那时起、我们改进了网络启动、dmesg 日志更好、但问题仍然存在。

    此致、

    Dimitris

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

    我会尝试从工作案例和非工作案例中为您提供最新的 dmesg 日志、但这可能需要我几天时间、因为我目前没有正式工作(我担任陪审团职责)。

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

    您好 Dimitrios、

    没问题。 我也要离开办公室几天。 如果您没有收到星期四下周的回复、请 ping 通该主题。

    软件版本

    我能让您验证所使用的 SDK 版本和内核分支吗? Linux 内核 6.12.43 与任何 Linux SDK 版本均无关。 Linux SDK 10.1.10 位于 Linux 内核 6.6 上。

    另请确认从何处获取 PRU 以太网固件。

    我想问的部分原因是 PRU 以太网代码仍在开发中。 我相信驱动程序已经上流了,但我不确定我们是否在供应商内核分支中携带了任何代码或 bug 修复程序,此时从上游分离出来。

    有关过去几周更新的更多信息?  

    您能详细谈谈“我们改进了网络启动、dmesg 日志更好、但问题仍然存在“吗?

    我们正在与开发团队交谈、以了解我们是否可以获得更多信息。

    此致、

    Nick