• 状态
  • 已锁定 已锁定
  • 回复 38 回复
  • 订户 0 订户
  • 视图 0 视图
  • 用户 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.

[参考译文] DP83822I：经过几小时的稳定性测试后网络丢失

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

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1609744/dp83822i-network-lost-after-several-hours-stability-test

器件型号： DP83822I

您好的团队、
我们有服务器单元在经过数小时的稳定性测试后丢失了网络。 我们使用 RMII 模式

迄今的调查结果：
1.发生问题时, TX 有数据包递增,但 RX 在 ping 操作后保持不变

root@**:~# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:32:4b brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
       2007598   18219      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
      12060576   36165      0       0       0       0 

2.我们根据数据表和 https://docs.ampnuts.ru/ti.com.datasheet/DP83822I/Application_note_SNLA266.PDF 尝试了 mii 环回

001F 8000 //软件复位（清除寄存器）

0000 6100 //将 DUT 编程为 100BASE-TX 模式并启用 MII 环回

001F 4000 //数字复位（不清除寄存器）

disable Auto-MIDX(0x0019): bit 15 set to 0

 ethtool --更改 eth0 速度 100 双工全自动协商关闭 

~# IP A
1: Lo: MTU 65536 qdisc noqueue 状态未知组默认 qlen 1000
链接/回送 00：00：00：00：00：00 brd 00：00：00：00：00：00：00
INET 127.0.0.1/8 范围主机低
valid_lft forever preferred_lft forever
inet6 ::1/128 范围主机
valid_lft forever preferred_lft forever
2：eth0： MTU 1500 qdisc FQ 状态关闭组默认 qlen 1000
链接/醚 e8：27：25：1b：79：98 brd ff：ff：ff：ff：ff：ff
~#

在上述步骤之后 eth0 不能启动,但在正常单元上它可以启动并有一个地址,我也可以通过 ping 操作看到两个 RX/TX 增量

3.另一项发现是 IP 链路 eth0 down && IP 链路 eth0 up 可以恢复网络通信

 当网络关闭（包括 0x0 至 0x1F、ethtool eth0 和 ethtool -S eth0）时、这是 0112.log  

您能帮助检查我是否遗漏了 MII 环路上的任何重要内容或者出现任何问题吗？

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

    您好、

    您针对 MII 环回所做的测试是什么？

    由于接口表示它没有载波、您能否先尝试禁用所有 PHY 中断掩码、看看这样是否消除了该问题？ Linux 可能会对来自 PHY 的连续 IRQ 做出过度反应。  
    此外、如果可能、您可以提供 PHY 的 dmesg 来查看发生此问题时是否有任何问题？ 由于 在 Linux 端对接口进行复位 (IP 链路设置断开/启动设备 eth0) 时 PHY 正常、因此我认为 Linux 上可能出现问题。

    此致、

    j

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

    对于 MII 环回、我应用了上述寄存器配置并 ping 子网地址、并通过“ip -s link show eth0“观察数据包、RX 和 TX 数据包在正常单元上都递增。

    正确、 当我屏蔽中断 (0x0012、0x0013) 时、eth0 可以接通、但在 网络丢失的装置上仍然无法恢复通信（RX 数据包仍然没有变化）。

    并且没有从 dmesg 中发现 

    ambarella-dwmac-eqos ffe000e000.ethernet: EthernetMac_index = 0
ambarella-dwmac-eqos ffe000e000.ethernet: EthernetMac_dma_cap = 40 bits
ambarella-dwmac-eqos ffe000e000.ethernet: select RMII mode
ambarella-dwmac-eqos ffe000e000.ethernet: User ID: 0x60, Synopsys ID: 0x53
ambarella-dwmac-eqos ffe000e000.ethernet:     DWMAC4/5
ambarella-dwmac-eqos ffe000e000.ethernet: DMA HW capability register supported
ambarella-dwmac-eqos ffe000e000.ethernet: RX Checksum Offload Engine supported
ambarella-dwmac-eqos ffe000e000.ethernet: TX Checksum insertion supported
ambarella-dwmac-eqos ffe000e000.ethernet: Wake-Up On Lan supported
ambarella-dwmac-eqos ffe000e000.ethernet: TSO supported
ambarella-dwmac-eqos ffe000e000.ethernet: Enable RX Mitigation via HW Watchdog Timer
ambarella-dwmac-eqos ffe000e000.ethernet: device MAC address 2a:34:b2:0a:cd:b1
ambarella-dwmac-eqos ffe000e000.ethernet: Enabled RFS Flow TC (entries=8)
ambarella-dwmac-eqos ffe000e000.ethernet: TSO feature enabled
ambarella-dwmac-eqos ffe000e000.ethernet: Using 40 bits DMA width
ambarella-dwmac-eqos ffe000e000.ethernet: stmmac_dvr_probe OK
ambarella-dwmac-eqos ffe000e000.ethernet eth0: PHY [stmmac-0:01] driver [TI DP83822] (irq=POLL)
ambarella-dwmac-eqos ffe000e000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
dwmac4: Master AXI performs fixed burst length
ambarella-dwmac-eqos ffe000e000.ethernet eth0: No Safety Features support found
ambarella-dwmac-eqos ffe000e000.ethernet eth0: No MAC Management Counters available                    
ambarella-dwmac-eqos ffe000e000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
ambarella-dwmac-eqos ffe000e000.ethernet eth0: configuring for phy/rmii link mode
ambarella-dwmac-eqos ffe000e000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
MACsec IEEE 802.1AE 
 ambarella-dwmac-eqos ffe000e000.ethernet eth0: Link is Down
 ambarella-dwmac-eqos ffe000e000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx


    但中断也保持不变 
    ~ # cat /proc/interrupts | grep eth0
 30:      23593          0     GIC-0 101 Level     eth0
 31:          0          0     GIC-0 100 Level     eth0
 32:          0          0     GIC-0  96 Level     eth0

    我认为这个 问题是由一些意外行为引起的 、但不知道可能的原因是什么。
    操作日志 

    ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    inet 169.254.167.167/16 scope link eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ea27:25ff:fe13:4ef9/64 scope link 
       valid_lft forever preferred_lft forever
~ # 
~ # pwd
/root
~ # 
~ # 
~ # ./phyrw.sh r 0x0012
0000
~ # ./phyrw.sh r 0x0013
0000
~ # 
~ # 
~ # ./phyrw.sh w 0x0012 0x00ff
~ # ./phyrw.sh r 0x0012
0x00ff
~ # ./phyrw.sh w 0x0013 0x00ff
~ # ./phyrw.sh r 0x0013
0x00ff
~ # 
~ # 
~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    RX:   bytes  packets errors dropped  missed   mcast           
      824296168  5839532      0       0       0       0 
    TX:   bytes  packets errors dropped carrier collsns           
    22069194316 18935380      0       0       0       0 
~ # 
~ #
~ # ./phyrw.sh w 0x001f 0x8000
~ #
~ # ./phyrw.sh w 0x0000 0x6100
~ # ./phyrw.sh w 0x001f 0x4000
~ # ./phyrw.sh r 0x0019
0x8421
~ # ./phyrw.sh w 0x0019 0x0421
~ # ./phyrw.sh r 0x0019
0x0421
~ #
~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq state DOWN group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
~ #
~ # ethtool --change eth0 speed 100 duplex full autoneg off
~ #
~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea27:25ff:fe13:4ef9/64 scope link
       valid_lft forever preferred_lft forever
~ #
~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    inet 169.254.167.167/16 scope link eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ea27:25ff:fe13:4ef9/64 scope link
       valid_lft forever preferred_lft forever
~ #
~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    RX:   bytes  packets errors dropped  missed   mcast           
      824296168  5839532      0       0       0       0 
    TX:   bytes  packets errors dropped carrier collsns           
    22069357779 18935815      0       0       0       0 
~ # 
~ # ping 169.254.1.2
No response from 169.254.1.2
~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    RX:   bytes  packets errors dropped  missed   mcast           
      824296168  5839532      0       0       0       0 
    TX:   bytes  packets errors dropped carrier collsns           
    22069361271 18935829      0       0       0       0
~ # 
~ # ethtool --change eth0 speed 100 duplex full autoneg on
~ # 
~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    RX:   bytes  packets errors dropped  missed   mcast           
      824296168  5839532      0       0       0       0 
    TX:   bytes  packets errors dropped carrier collsns           
    22069458924 18936100      0       0       0       0 
~ # 
~ # ethtool eth0
Settings for eth0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: yes
~ #

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

    您好、  

    有意思。  

    这种情况、您能为我做一些事情吗？
    执行 MII 环回时、您可以检查 ethtool -S eth0 统计信息吗？ 我们希望确保 RX 数据包递增不是由于内部内核环回造成的。  

    此外、一旦发生这种情况、您能否将 PHY 置于反向环回模式、看看您是否可以将数据包从 LP 环回到 PHY、然后返回到 LP？ 这将确保 MDI 侧也能正常工作。  

    此致、
    j


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

    您好 J
    是的、 复制后将检查 ethtool -S eth0、我们重新启动器件并重新开始测试。

    查看您是否可以将数据包从 LP 环回到 PHY 并返回到 LP

    我怎么能看它是否工作,通过上述相同的方式? 还需要屏蔽中断？

    谢谢！

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

    您好、Chris、  

    我们通常建议使用 Wireshark 捕获数据包、使用 pktgen 生成数据包。 您可以将 PHY 置于反向环回模式 (0x16 = 0x10)。 并使用来自 LP 的 pktgen（如果 LP 是 Linux）发送数据包。 由于反向环回、数据包应发送回 LP、您可以使用 Wireshark 捕获该数据包、以查看该数据包是否打算用于 DUT。 您应该不需要屏蔽中断。  

    此致、
    j

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

    e2e.ti.com/.../after_5F00_loopback.loge2e.ti.com/.../before_5F00_loopback.log

    我做了 MII 环回并捕获了 ethtool -S eth0。
    我现在尝试安装 pktgen

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

    您好、Chris、  

    您是否还在 PHY 的寄存器 15h 上看到任何错误？ 它跟踪传入符号错误。  

    我看到没有接收到任何数据包、即使它们同时针对常规数据包计数和 Q0 数据包计数进行传输也是如此。  
    正在传输的数据包大小是多少？  
    提取到 PHY 中的 XI 时钟的 ppm 是多少？
    发生这种情况时、您还可以检查 PHY 的寄存器 17h 吗？ 我想知道 RMII FIFO 是否有问题。  

    此致、
    j

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

    您好 J
    我读取了 重现问题时的状态、好像没有错误、如果 MDI 侧出现问题、 我们是否需要关注任何寄存器？ 

    ~ # 
~ # ./phyrw.sh r 0x0015
0000
~ # ./phyrw.sh r 0x0017
0x0065
~ #

    数据包大小应为默认值（56 字节） 
    ping -c 3 169.254.190.191
PING 169.254.190.191 (169.254.190.191) 56(84) bytes of data.

    正常单位的 ppm 不超过 20、但我们将在出现问题时仔细检查

    我设法使用 AF_packet PMD 代替 pktgen、因为 DPDK 不支持我的虚拟 PCIe 设备。

    具有 Recerse 设置的正常单元测试 

    testpmd> set fwd mac
Set mac packet forwarding mode
testpmd> start
mac packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP allocation mode: native
Logical Core 3 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  mac packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
    Rx offloads=0x0 Tx offloads=0x0
    RX queue: 0
      RX desc=256 - RX free threshold=0
      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
      RX Offloads=0x0
    TX queue: 0
      TX desc=256 - TX free threshold=0
      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
      TX offloads=0x0 - TX RS bit threshold=0
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 92         RX-missed: 0          RX-bytes:  27133
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 1          TX-errors: 0          TX-bytes:  253

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:            0
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  ---------------------- Forward statistics for port 0  ----------------------
  RX-packets: 2              RX-dropped: 0             RX-total: 2
  TX-packets: 2              TX-dropped: 0             TX-total: 2
  ----------------------------------------------------------------------------

  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
  RX-packets: 2              RX-dropped: 0             RX-total: 2
  TX-packets: 2              TX-dropped: 0             TX-total: 2
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 93         RX-missed: 0          RX-bytes:  27386
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 2          TX-errors: 0          TX-bytes:  506

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:           64
  Tx-pps:            0          Tx-bps:           64
  ############################################################################
testpmd>


    在断开设备与主机的连接时进行测试 
    testpmd> clear port stats 0

  NIC statistics for port 0 cleared
testpmd> set fwd mac
Set mac packet forwarding mode
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 0          RX-missed: 0          RX-bytes:  0
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 0          TX-errors: 0          TX-bytes:  0

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:            0
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd> start
mac packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP allocation mode: native
Logical Core 3 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  mac packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
    Rx offloads=0x0 Tx offloads=0x0
    RX queue: 0
      RX desc=256 - RX free threshold=0
      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
      RX Offloads=0x0
    TX queue: 0
      TX desc=256 - TX free threshold=0
      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
      TX offloads=0x0 - TX RS bit threshold=0
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 21         RX-missed: 0          RX-bytes:  4403
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 0          TX-errors: 0          TX-bytes:  0

  Throughput (since last show)
  Rx-pps:            2          Rx-bps:         3904
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  ---------------------- Forward statistics for port 0  ----------------------
  RX-packets: 1              RX-dropped: 0             RX-total: 1
  TX-packets: 1              TX-dropped: 0             TX-total: 1
  ----------------------------------------------------------------------------

  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
  RX-packets: 1              RX-dropped: 0             RX-total: 1
  TX-packets: 1              TX-dropped: 0             TX-total: 1
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 22         RX-missed: 0          RX-bytes:  4656
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 1          TX-errors: 0          TX-bytes:  253

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:           80
  Tx-pps:            0          Tx-bps:           80
  ############################################################################


    我将测试相同的方式,当再次复制,如果方法没有问题

    感谢您发送编修。

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

    您好、Chris、  

    如果 MDI 侧出现问题、寄存器 15h 可以捕获传入数据包的符号错误。 否则、链路状态是查看 MDI 侧是否有任何问题的最明显的指示器。  

    看起来反向环回在正常模式下工作。 出现问题时、请告诉我它是如何工作的。  

    此致、
    j

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

    尊敬的 J：
    此问题在 单个设备连接到主机的干净环境中再次重现。
    我做了 Mac 转发 测试与 testpmd 之前和设置反向模式后,它显示相同的行为 统计数据.

    解决方案 

    testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 0          RX-missed: 3          RX-bytes:  0
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 0          TX-errors: 0          TX-bytes:  0

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:            0
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd> 
testpmd> set fwd mac
Set mac packet forwarding mode
testpmd> start
mac packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP allocation mode: native
Logical Core 3 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  mac packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
    Rx offloads=0x0 Tx offloads=0x0
    RX queue: 0
      RX desc=256 - RX free threshold=0
      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
      RX Offloads=0x0
    TX queue: 0
      TX desc=256 - TX free threshold=0
      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
      TX offloads=0x0 - TX RS bit threshold=0
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 563        RX-missed: 53         RX-bytes:  414758
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 51         TX-errors: 0          TX-bytes:  4552

  Throughput (since last show)
  Rx-pps:           15          Rx-bps:        90160
  Tx-pps:            1          Tx-bps:          984
  ############################################################################
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  ---------------------- Forward statistics for port 0  ----------------------
  RX-packets: 73             RX-dropped: 0             RX-total: 73
  TX-packets: 73             TX-dropped: 0             TX-total: 73
  ----------------------------------------------------------------------------

  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
  RX-packets: 73             RX-dropped: 0             RX-total: 73
  TX-packets: 73             TX-dropped: 0             TX-total: 73
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 585        RX-missed: 53         RX-bytes:  416348
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 73         TX-errors: 0          TX-bytes:  6142

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:          168
  Tx-pps:            0          Tx-bps:          168
  ############################################################################
testpmd>


    之后 
    testpmd> clear port stats 0

  NIC statistics for port 0 cleared
testpmd> 
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 0          RX-missed: 9          RX-bytes:  0
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 0          TX-errors: 0          TX-bytes:  0

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:            0
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd> set fwd mac
Set mac packet forwarding mode
testpmd> start
mac packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP allocation mode: native
Logical Core 3 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  mac packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
    Rx offloads=0x0 Tx offloads=0x0
    RX queue: 0
      RX desc=256 - RX free threshold=0
      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
      RX Offloads=0x0
    TX queue: 0
      TX desc=256 - TX free threshold=0
      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
      TX offloads=0x0 - TX RS bit threshold=0
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 550        RX-missed: 21         RX-bytes:  46726
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 38         TX-errors: 0          TX-bytes:  2705

  Throughput (since last show)
  Rx-pps:           17          Rx-bps:        11632
  Tx-pps:            1          Tx-bps:          672
  ############################################################################
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  ---------------------- Forward statistics for port 0  ----------------------
  RX-packets: 47             RX-dropped: 0             RX-total: 47
  TX-packets: 47             TX-dropped: 0             TX-total: 47
  ----------------------------------------------------------------------------

  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
  RX-packets: 47             RX-dropped: 0             RX-total: 47
  TX-packets: 47             TX-dropped: 0             TX-total: 47
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.
testpmd> 
testpmd> show port stats 0

  ######################## NIC statistics for port 0  ########################
  RX-packets: 559        RX-missed: 1015       RX-bytes:  47104
  RX-errors: 0
  RX-nombuf:  0         
  TX-packets: 47         TX-errors: 0          TX-bytes:  3083

  Throughput (since last show)
  Rx-pps:            0          Rx-bps:            0
  Tx-pps:            0          Tx-bps:            0
  ############################################################################
testpmd>


    MDI 侧的任何内容都不会错过。 我们是否应该寻找 RMI 侧或自检来确定 更近的路径？  谢谢你

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

    您好、Chris、  

    在这两种情况下、似乎都丢失了一些 RX 数据包。  
    我想知道数据包是否持续丢失导致连接几乎冻结。  
    通过寄存器配置重新启动自动协商是否能解决此问题？ 我想知道连接是否需要更新。 您可以将寄存器 0h 的位 9 设置为高电平。  

    此外、您可以执行 MII 环回并从有问题的电路板的 MAC 侧发送数据包、然后查看是否接收到任何 RX 数据包错误。  
    您可以通过将寄存器 0h 的第 14 位设置为高电平来将 PHY 设置为 MII 环回。  

    请告诉我您的想法。  

    此致、
    j

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

    如果问题 更接近 MAC 侧、建议的调试方法是什么、
    例如

    1.use a force way。 这是  强制链路 100 米全无 autonego。 （需要在两侧设置）

    如果 phy-device 可以支持、则进行 2.phy-tx-PHASE 调整

    我们更喜欢调整阶段以再次验证、您能提供建议并指导我们更多、如果您有更多见解、真的很感激您

    谢谢 J

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

    您好、Chris、  

    我同意 MDI 方面似乎没问题。 之所以发生这种情况、是因为 PHY 使用 RMII、并且 RMII 在 FIFO 和时钟方面可能会存在一些问题。  

    您是否能够检查进入 PHY 的晶体的 ppm？
    此外、您能否将 RMII 弹性缓冲区大小设置为最大值并查看是否发生了问题？
    您可以将寄存器 17h 的位[1：0]设置为 00。 增加缓冲区大小将增加 RMII 时钟与恢复数据之间频率变化的容差。  

    此致、
    j

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

    尊敬的 J：

    我与 Chris 合作。 现在、我们已经按照您的建议修改了 REG (0x0017)。 两个装置已经运行了 2 天、但仍在运行。 在~1 天后可能重现之前。 这是一个很好的标志。 在读取 REG 0x0017 的详细信息时、我发现器件中的 bit[3]始终为 1、这表示存在某些问题吗？ 当我们将位[1：0]从 1 更改为 0 时、会增加容差、这是由于时钟不匹配导致的误差吗？ 您能详细介绍一下吗？ 谢谢。

    此致、

    爱马仕

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

    尊敬的 Chenhui：  

    很高兴听到。 发生该错误的原因可能是 RMII 信号连接中的某个位置存在时钟不匹配。 问题可能来自不满足 ppm 要求的振荡器/晶体。 增加弹性缓冲区的大小会增加 ppm 容差、因此这似乎是错误消失的原因。  

    如果 RMII FIFO 持续溢出、您能否降低频率容差并查看它是否仍然存在？

    此致、
    j

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

    尊敬的 J：

    我们的所有器件都使用 REG17[1：0]中的默认值 01、这是现在容差的最小值、但只有某些器件存在此问题。 实际上我的问题是、当我们读取 REG17 时、我们看到[3]对于所有单元都是 1、这是否意味着已经发生了 RX FIFO 溢出？ 这是一个问题还是风险？

    此致、

    爱马仕  

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

    尊敬的 Chenhui：

    我建议仔细检查 XI 时钟的 ppm。 这可能是因为时钟的 ppm 高于建议值。

    此致、

    j

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

    尊敬的 J：

    感谢您的快速答复。 是的、我们将仔细检查、我们计划使用外部振荡器进行检查。 顺便说一下、今天我从单位中读取 REG17、它会变为 0x60、因为在我将容差更改为 00 后、RX 溢出位就消失了。 我想这也是个好主意。

     此致、

    爱马仕

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

    FIFO 状态位仅在读取时被清除、因此在某个时刻可能发生了溢出、但自此之后没有发生。

    此致、

    j

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

    尊敬的 J：

    因此、如果我重复读取 REG17、我总是使 RX 溢出位为 1、这意味着继续发生 RX FIFO 溢出？  

    root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017
0x0065
root@axis-e8272522202a:~# /tmp/phytool read eth0/1/0x0017

    最棒的餐厅

    爱马仕

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

    尊敬的 Chenhui：

    可能有一个机会。然而,我将不得不进一步调查。

    此致、

    j

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

    您好 J：

       我是与 Chris & Hermes 合作的电子工程师、关于 PHY 上的 XI 输入、我们在 DP83822 上使用了 RMII 主模式、这意味着我们使用了从 SOC 到 XI 的 25MHz 时钟、PHY 生成 50MHz 返回到 RMII 的 SOC、我们还为外部晶体 25MHz 保留焊盘、我附上了原理图文件以供您参考、该文件之前已由 TI 团队审查过。

    e2e.ti.com/.../M3925_2D00_R_5F00_Main_5F00_schematic.pdf

       我还怀疑来自 SOC 的时钟存在问题、并检查了 PPM 是否不超过 20ppm（约 12ppm）、因此我尝试使用外部晶体、并且问题仍然存在、但当问题发生时、我仍然捕获了外部晶体 PPM、PPM 甚至低于 3ppm。

       我检查了 REG17 位 1：0 关于弹性缓冲区大小、它允许 50MHz 和恢复数据之间的频率变化容差、您能更深入地解释一下什么是“50MHz"和“和“恢复数据“在我们的用例中、“50MHz"是否“是否表示从 PHY 到 SOC 的输出？ 实验表明、来自 SOC 或外部晶体的 XI 似乎良好、并且问题在 两个时钟上都发生、似乎与 XI 时钟无关。

       谢谢！

       此致、

       TED


     

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

    尊敬的 J：

    抱歉、我需要更正一点、REG17 显示设置了位 2 的 0x0065、因此是 RX FIFO 下溢、而不是溢出。

     此致、

    爱马仕

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

    尊敬的 Chenhui 和 Wenjun：  

    感谢您提供详细信息。 似乎由于 XI 时钟而没有发生此问题、但由于某种原因、增加弹性缓冲区的大小有所帮助。  


     我检查了 REG17 位 1：0 关于弹性缓冲区大小、它允许 50MHz 和恢复数据之间的频率变化容差、您能更深入地解释一下什么是“50MHz"和“和“恢复数据“在我们的用例中、“50MHz"是否“是否表示从 PHY 到 SOC 的输出？ 实验表明,来自 SOC 或外部晶体的 XI 似乎很好,问题发生在 两个时钟上,它似乎不应该与 XI 时钟有关。[/报价]

    是的、在您的情况下、50MHz 将是 PHY 向 MAC 提供的时钟。 恢复数据是指从 MDI 侧到 RMII FIFO 处理的数据。  

    基于此、我想知道缓冲区为什么持续不足。 我想建议的一点是减小 IPG 或增加数据包大小可以防止 FIFO 下溢。  

    此致、
    j

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

    您好 J：

       稍微更新 PPM、实际上当问题发生时才测量 PPM、是在我们发现网络丢失后测量的、监测 PPM 值是非常困难的、因为我们不知道它何时会断开链路、但正如晨辉所说、  PPM 下溢会持续发生、如果它与时钟 PPM 有关、我相信我始终可以测量并获得较大的结果。

       下溢状态是否会像上溢那样受时钟 PPM 的影响？

       

        

       

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

    尊敬的 Wenjun：

    我不确定为什么会出现下溢。 一个原因可能是 XI 时钟的 ppm、但我想知道它是否取决于系统中数据包的发送方式、这就是我建议以不同方式发送数据包的原因。

    下溢状态意味着 MII 端抓取的数据包速度快于来自 MDI 端的数据包。 因此、这可能是应用特定的问题、或者如果有任何导致下溢的硬件问题、

    此致、

    j

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

    尊敬的 J：
    将 0x0017 的[1：0]位设置为 0x00 后、网络 最终通过 更长的测试丢失。 我将该寄存器与 网络断开（右侧）时的初始日志进行比较。 链路伙伴似乎输入了错误的状态、您能否 就此测试结果分享更多想法？

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

    您好、Chris、  

    这是不幸的。  

    您是否知道网络连接丢失时是否有大量流量？ 我想知道在失去网络稳定性时是否会出现功率下降。  

    我注意到寄存器 17h 的值会发生变化。 这会更改位[1：0]、因此弹性缓冲区的大小最有可能更改、并且可能导致网络崩溃。  

    您能否确认寄存器写入可能发生在哪里？

    此致、
    j

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

    您好 J
    我 想澄清的是,右列寄存器是缺省设置的网络丢失单元（没有增加弹性缓冲区的大小）。 不知道 与缓冲区增加的失败测试（左列）进行比较是否有意义。 我想知道 当我们增加缓冲区时、网络连接不应该更糟、否则不应该产生负面影响？ 我们是否还有其他线索可以进一步验证？
    感谢您的建议。

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

    您好、Chris、  

    感谢您的澄清。 我查看了寄存器的比较、没有看到任何明显的配置变化。 在这种情况下、MAC 侧可能会出现问题。 网络中断时、MAC 端是否有任何 dmesg 日志？

    此致、
    j

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

    尊敬的 J：
    它只有启动日志、但网络中断时没有重要信息、如果  您建议查看任何调试日志、我们将尝试获取该日志。
    谢谢！

    Ambarella dwmac-eqos ffe000e000.Ethernet eth0：PHY [stmmac-0：01]驱动程序[TI DP83822 (IRQ=POLL)
    Ambarella -dwmac-eqos ffe000e000.Ethernet eth0：寄存器 MEM_TYPE_PAGE_POOL RxQ-0
    dwmac4：主 AXI 执行固定的突发长度
    Ambarella－dwmac－eqos ffe000e000．以太网 eth0：未找到安全功能支持
    Ambarella dwmac-eqos ffe000e000.Ethernet eth0：没有可用的 MAC 管理计数器
    Ambarella dwmac-eqos ffe000e000.Ethernet eth0：支持 IEEE 1588-2008 高级时间戳
    Ambarella dwmac-eqos ffe000e000.Ethernet eth0：配置 phy/RMII 链路模式
    简单卡:Ambarella fix DAI 时钟 12288000。
    简单卡:Ambarella fix DAI 时钟 12288000。
    Ambarella dwmac-eqos ffe000e000.Ethernet eth0：链路接通 — 100Mbps/full — 流量控制关闭
    MACsec IEEE 802.1AE
  • 0
    TI__Guru**** 2815985 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Chris、  

    我注意到链路中断没有日志。 链路是否曾被断开？  

    此外、我们可能需要使 MII 环回以某种方式工作。 MII 路径中的某个位置似乎出现了中断、我不确定此时发生了什么中断。  

    我知道您之前使用过 MII 环回模式、但因为链路未接通、所以这不起作用。  

    您能尝试使用数字环回运行 MII 环回吗？ 这些环回模式应为您提供链路状态、因此您应该能够发送数据包以查看 MII 路径是否始终正常工作。  



    您可以将寄存器 16h 设置为 04h 以启用数字环回。  

    此致、
    j

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

    谢谢 J、

    我可以看到链路 IP、您的意思是发送数据包从器件发送到 主机右侧？ 关于 MII 路径、很遗憾我无法创建它、因为该器件的工具有限。 

    ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    inet 169.254.167.167/16 scope link eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ea27:25ff:fe13:4ef9/64 scope link 
       valid_lft forever preferred_lft forever
~ # 
~ # ./phyrw.sh r 0x0016
0x0144

~ # ping 169.254.78.31
No response from 169.254.78.31
~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff
    RX:    bytes  packets errors dropped  missed   mcast           
      4534792374 62264419      0       0       0       0 
    TX:    bytes  packets errors dropped carrier collsns           
    156619724437 31208994      0       0       0       0 
~ #

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

    您好、Chris、  

    您走在正确的轨道上。 如果在 Linux 上启用混杂模式、MAC 发送的数据包将环回到 MAC、但不会丢弃、因此您应该会在 ping 结束后看到数据包计数器递增。  

    我建议的测试程序如下：
    1、将 0x16 = 0x0104 写入 PHY 寄存器。
    2.通过 ip -s link show eth0 或 sudo ethtool -S 检查当前数据包状态
    3. ping IP 地址
    请注意、由于数据包正在环回、因此 ping 将不起作用。
    4.取消 ping 并再次检查数据包状态。 如果 MII 路径始终正常、我们应该能够看到数据包递增。  

    此致、
    j

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

    尊敬的 J：
    谢谢你和我测试,如你所说。
    当我在正常单元上为 0x16 设置 0x0104 时、数据包在 RX 和 TX 端都持续增长。
    在网络丢失的复制单元上、当启用  混杂模式和 ping IP 地址时、我无法看到 RX 数据包递增。 因此、与普通单元相比、它得出的结论是 MII 路径当时被破坏了 

    ~ # ./phyrw.sh r 0x0016 

0x0100 

~ # ./phyrw.sh w 0x0016 0x0104 

~ # ./phyrw.sh r 0x0016 

0x0104 

~ #  

~ #  

~ # ip -s link show eth0 

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000 

    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff 

    RX:    bytes  packets errors dropped  missed   mcast            

      3962834638 50563983      0       0       0       0  

    TX:    bytes  packets errors dropped carrier collsns            

    132489338727 33215264      0       0       0       0  

~ #  

~ # ip a 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 

    inet 127.0.0.1/8 scope host lo 

       valid_lft forever preferred_lft forever 

    inet6 ::1/128 scope host  

       valid_lft forever preferred_lft forever 

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000 

    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff 

    inet 169.254.167.167/16 scope link eth0 

       valid_lft forever preferred_lft forever 

    inet6 fe80::ea27:25ff:fe13:4ef9/64 scope link  

       valid_lft forever preferred_lft forever 

~ #  

~ # ping 169.254.78.31 

No response from 169.254.78.31 

~ # ip -s link show eth0 

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000 

    link/ether e8:27:25:13:4e:f9 brd ff:ff:ff:ff:ff:ff 

    RX:    bytes  packets errors dropped  missed   mcast            

      3962834638 50563983      0       0       0       0  

    TX:    bytes  packets errors dropped carrier collsns            

    132489353636 33215352      0       0       0       0  

~ #


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

    您好、Chris、  

    我同意 MII 路径不起作用。 您能否确保 RMII 布线长度匹配且在布局上的 6000mil 以内？ 此外、如果这是由于 RMII 路径上的时序违例引起、则启用 TX 时钟移位可能会解决该问题。 您可以将寄存器 17h 的位 8 设置为高电平来启用此功能。  



    请告诉我。  

    此致、
    j

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

    您好 J：

    关于 RMII 布线长度匹配的情况、我之前检查过、最大差异是 TXD0 与基准 CLK 的比较、但仍然 满足 DP83822 的要求、但无论如何、我们将尝试在下一批中改进这一点、顺便说一句、对于 RMII 布线、长度匹配要求是否包括来自 SOC 的输入时钟（在本例中为 25MHz）？

    ETH_CRS_DV

    57.507mm

    ETH_TXD0_POC14

    74.978 毫米

    ETH_TXD1_POC1

    67.439 毫米

    ETH_TXEN

    64.632 毫米

    ETH_RXD0

    63.063 毫米

    ETH_RXD1

    60.957 毫米

    ETH_CLK_RX

    62.332mm

    对于您建议的 RMII TX 时钟移位、我记得我们之前已经尝试过这种方法、问题仍然存在、但无论如何、Chris 将再次尝试。

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

    尊敬的 Wenjin：

    我懂了。 XI 时钟路径不必进行长度匹配。 我们通常建议 MII 路径保持在 50mil 长度的匹配范围内。 这个值约为 1.27mm、因此 MII 路径绝对不在我们的建议范围内。

    您可以参考本文档了解更多信息：  

    https://www.ti.com/lit/an/snla387/snla387.pdf?ts = 1773744254749

    如果 TX 时钟移位不起作用、我认为长度匹配的 RMII 路径是理想的解决方案。 如果要使用当前版本的电路板、那么像我们之前研究的那样增加 RMII FIFO 大小是我可以提供的最佳权变措施。
    此致、

    j