[参考译文] DP83867IR：接收 DP83867IR 的挂起

您好、  

在网络环境不良的情况下、DP83867 可能会断开链路。 但是、DP83867 在接收到无效数据时不会断开链路。 它会增加 RECR 值。 PHY 不会丢弃数据、而是将错误传递给 MAC。 如果链路断开、驱动程序应该能够检测到链路断开。 如果您对设备进行软重置、则可能会恢复链接。 如果这不起作用、则可能需要硬复位才能备份链路。  

交换机和 PHY 之间的电缆长度是多少？ 此外、您还可以通过访问该寄存器来检查链路质量：



此致、  
j

您好：

我与 J 同在一个团队、将继续处理此查询。 我想进一步了解当前的信号链。 RECR 寄存器仅指示 PHY 检测到进入 MDI 的符号错误。PHY 的链路伙伴是什么、是 L2 开关？

通常、一旦进行自动协商和链路训练、连接就不会降级；这表示在这一周的测试中发生了变化。 PHY 是否重新链接（从而再次重新执行自动协商和链路训练阶段）？

此致、
Gerome

感谢您的支持。

PHY 不会丢弃数据、而是将错误传递给 MAC。 如果链路断开、驱动程序应该能够检测到链路断开。 如果您对设备进行软重置、则可能会恢复链接。 如果这不起作用、则可能需要硬复位才能备份链路。  [/报价]

在我们的测试期间、没有链路断开的迹象。 手动执行 PHY 的软复位命令、挂起已恢复。 通过软复位丢弃链路、然后驱动程序检测到链路断开并初始化 PHY、从而从挂起中恢复。 因此、无需硬复位即可从此挂起中恢复。

驾驶员如何识别此情况并自动执行软重置？

如果驱动程序无法检测到这种情况、PHY 挂起对我们来说将是一个致命问题。

交换机和 PHY 之间的电缆长度是多长？

我们使用的是 3m 的 CAT-6 电缆。

您可以通过访问该寄存器来检查链接质量

我们正在进行复制测试、同时监控链路质量寄存器 A-D 测试开始时、RECR 为 0、链路质量寄存器表示“优秀“（分别为 61、22、90、50）。

PHY 的链路伙伴是什么、是 L2 交换机？

是的。 PHY 连接到 L2 开关。 L2 开关是 Buffalo  LSW-LSW-16NSRR GT。

通常、自动协商和链接训练一旦发生、连接就不会降级；表明在这一周的测试中发生了变化。 PHY 是否重新链接（从而再次重新执行自动协商和链路训练阶段）？

在测试过程中、我们没有弄断或拔下电缆。

因此我们没有特意重新链接 PHY。

此致、  

[/quote]

您好、Ito-San、

这种行为的可重现性如何？ 目前尚不清楚 ping 如何随着时间的推移而变成不良、因此需要对信号链进行更深入的分析、以便了解问题所在。

此致、

Gerome

您好 Gerome、

这通常是通过连续运行我们的原型大约一周来重现的。 主管目前不在、因此我们将在下周回复有关复制的详细信息。

此致、

ITO

您好、Ito-San、

这是相当奇怪的,但我会等待与你的负责人. 我们需要了解在信号路径良好与不良之间发生了哪些变化（如果没有链路丢弃/重新训练）。

此致、
Gerome

您好 Gerome、

我们对延迟的回复深表歉意。
我们将解释我们进行的其他调查以及我们对结果的假设。

1.出现问题的环境:
自初始开机自检以来、重复出现 PHY 挂起问题的环境没有改变。
但是、由于本报告、AM6442 原型将以一秒的间隔执行附加的通信状态监控命令。 该命令是如下所示的 shell 脚本：

2、连续运行的结果:
这一次、即使连续运行的时间比最初预期的时间更长、也不再发生通信挂起。
相反、Link Down 和 Link up 执行消息被输出到控制台。
我们通过这些消息确认发生了通信异常、并且链路已自动重新连接。

3、附件:
- shell 脚本执行结果: recr_dmesg_summary2.log
链路重新连接发生了三次。
我们在链接之前收集了 30 秒的命令输出、在链接 reconnection.e2e.ti.com/.../recr_2B00_dmesg_5F00_summary2.log 之后收集了 15 秒的命令输出

4.关于结果的问题:

(1) 我们预计这种现象如下。 这是正确的吗？
PHY 检测到网络异常并重新连接链路。
以太网驱动程序还监控 PHY 状态并通知控制台已重新连接链路。

(2) PHY 如何检测网络异常？
在链路重新连接之前和之后、接收错误计数器 RECR 略微增加。
此外、通信质量值​​LINKA/LINKB/LINKC/LINKD 略有变化。

(3) 这种现象与以前的现象大不相同。 原因可能是什么？
区别在于定期执行监控命令。
此操作是否会改变 PHY 的行为？

提前感谢您。

此致、

ITO

尊敬的 Ito-San：

感谢您提供的信息。 PHY 似乎确实丢弃了链路、如您的分析所确认、这会导致其在准备就绪后重新建立链路。 这将导致开展新的链路培训。

PHY 由于数据包错误而按预期丢弃了链路。 了解数据包错误的原因非常重要。 寄存器 0x15 (RECR) 指示 PHY 发生了损坏、因此需要对链路伙伴进行 BER 分析、了解链路伙伴为什么为 A) 向 DUT 发送损坏的数据包、或 B) MDI 介质容易损坏。

此致、

Gerome

您好 Gerome、

感谢您的答复。

(3) 这种现象与以前的现象非常不同。 原因可能是什么？
区别在于定期执行监控命令。
此操作是否会改变 PHY 的行为？

我们理解您的解释是正确的。

但是、我们认识到您没有充分回答问题 (3)、这是我们最想知道的问题。

请回答问题 (3)。

我们非常关注您最初报告的问题、即 PHY 挂起一旦发生、便无法自动恢复。

我们希望避免 PHY 即使网络质量较差并且 PHY 从 MDI 介质接收到损坏符号的问题仍然挂起。

我们想知道定期运行 recr.sh 是否是避免此挂起问题的一种解决方法。

此致、

ITO

尊敬的 Ito-San：

监控不应影响任何内容、因为这只是一个动态状态指示器。

关于 J 关于不丢弃链路的初始注释、我们要重新措辞；PHY 不会从单个 RX_ER 丢弃链路、而是在一段时间内累积的 RX_ERS 时丢弃链路；这表示信号链出现显著降级。

请告知我们环回测试的结果、以帮助进一步调查错误的来源。

此致、

Gerome

伊藤是在暑假,所以我,他的合作者,是代表他发帖。

您好 Gerome、
感谢您的答复。

监控不应影响任何内容、因为这只是一个动态状态指示符。

您的上述解释与我们所经历的现象不同。

在不进行监控的情况下、PHY 会在几天的通信后挂起。
PHY 挂起后、通信不会自动恢复。
因此、我们手动执行链路断开和链路接通以恢复通信。

另一方面、在进行监控的情况下、PHY 会自动执行链路断开和链路接通。
在这种情况下、我们会在监控过程中以 1 秒的间隔从 PC 连续 ping 我们的原型、并且 ping 不会连续两次失败。
要解决挂起问题、我们需要使用以太网驱动程序或类似驱动程序来检测 PHY 挂起问题。
请告诉我们如何检测 PHY 挂起情况。

PHY 不会从单个 RX_ER 断开链路、而是在一段时间内累积 RX_ERS；

我们无法实际确认您在我们的原型中描述的行为。
我们以 1 秒的间隔监测 RX_ERS 的数量、但在短时间内没有观察到 RX_ERS 的数量显著增加。
在哪段时间内以及 PHY 断开链路之前必须发生多少 RX_ERS？
我们使用的 SDK 09_0x 为 09.00.00.03、确切地说是这样。

请告知我们回送测试的结果、以帮助进一步调查错误的来源。

“环回测试“是指哪种通信测试？
在我们的复制环境中、我们每隔 1 秒使用 ping 通信。

此致、

Ohno

你好 Ohno-san、

感谢您的更新。 从硬件的角度来看、从器件的状态机的角度来看、为链路轮询寄存器 0x1 不会有任何变化。 我不建议将链接轮询与功能关联起来、因为除了前者是状态指示器之外、它们之间没有关联。 通信挂断还有其他原因。

理想情况下、对于通信、RX_ER 应为 0x0。 然而,在 Ito-san 以前提供的日志中,这是一个很高的价值。 因此、我担心信号链的整体运行状况、建议采用环回测试。

ping 只是表面水平测试。 我建议与 MAC 核对如何设置 Ethtool、并根据发送的数据日志检查 MDI 是否损坏。 以下调试应用手册可能会有所帮助：

https://www.ti.com/lit/an/spradj8/spradj8.pdf?ts = 1757024772540 &ref_url=https%253A%252F%252Fwww.google.com%252F

此致、

Gerome

您好 Gerome、  

感谢您的答复。
正如您所指出的、我们在定期监控期间遇到了反复出现的 PHY 挂起问题。
根据您的建议、我们目前正在研究参考文献、并考虑一种自动检测 PHY 挂起并从这些挂起中恢复的策略。
我们将在下周报告我们的战略、因此我们感谢您提供建议。

此致、

ITO

您好、Ito-San、

目前、在我们获得有关信号链断裂位置的更好信息之前、没有任何建议。 请结合我的环回测试和报告结果建议、继续执行您的策略。 这样可以更好地了解情况。

此致、

Gerome

您好 Gerome、

很抱歉耽误了回复。
我们无法重现此问题、目前正在等待问题再次出现、以便尝试您的建议。 这一进程已持续了大约一周。
在我们收集更多信息的同时、请耐心等待。

此致、

ITO

尊敬的 Ito-San：

感谢您的查询。 我会等待你的下一个职位。 您已经提到、未监控链路状态与发出清单之间存在关联。 这在上周仍然是这样吗？

此致、

Gerome

您好 Gerome、

我们很抱歉晚才回复。
我们目前不确定 PHY 环回测试 BIST 的正确程序、并且测试未成功。
因此、我们需要您的帮助。
请根据结果指出我们测试程序中的任何错误。
我们的 PHY 环回测试程序如下所示。

1.参考:我们遵循了以下文档中的“7.4.4 环回模式“:
https://www.ti.com/lit/ds/symlink/dp83867cs.pdf

2.实际器件：使用具有四个以太网端口（以太网 1-4）的 AM6442 进行原型设计
PHY：DP83867ERGZ
Linux：SDK 09_00_00_03
端口：Ethernet1。
我们还测试了 Ethernet2、Ethernet3 和 Ethernet4、但结果是相同的。
由于它是环回、因此端口的网络连接不应相关。

3.环回:数字环回。
我还执行了 PCS 环回和模拟环回、但结果是相同的。

4.执行的命令和结果:
请注意、mdio-tool-ext.sh 是如下所示的 shell 脚本。

1) 接口状态被检查,没有发现异常。
# ip 地址 show
1：低： 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
2：以太网 4： MTU 1500 qdisc mq 状态关闭组默认 qlen 1000
链接/醚 00：00：64：B6：71：A4 Brd ff：ff：ff：ff：ff：ff：ff：ff：ff
3：以太网 3： MTU 1500 qdisc mq 状态关闭组默认 qlen 1000
链接/醚 00：00：64：B6：71：A5 brd ff：ff：ff：ff：ff：ff：ff：ff：ff
4：na_bb-eth0： MTU 1500 qdisc pfifo_fast 状态下行组默认 qlen 1000
链接/协议 02：00：00：00：00：17 brd ff：ff：ff：ff：ff：ff permaddr 32：da：56：7d：54：6B
altname enp3s0
5：na_bb-eth1： MTU 1500 qdisc pfifo_fast 状态下行组默认 qlen 1000
链路/以太网 02：00：00：00：00：18 brd ff：ff：ff：ff：ff：ff permaddr 4e：1b：B5：89：e1：ef
altname enp4s0
6：tap0： MTU 1500 qdisc noop 状态关闭组默认 qlen 1000
链路/醚 f2：C4：20：35：45：A3 brd ff：ff：ff：ff：ff：ff：ff：ff
7：Ethernet2： MTU 1500 qdisc mq 状态关闭组默认 qlen 1000
链接/醚 00：00：64：B6：71：A6 brd ff：ff：ff：ff：ff：ff：ff：ff：ff
8：以太网 1： MTU 1500 qdisc mq 状态关闭组默认 qlen 1000
链接/醚 00：00：64：B6：71：A7 Brd ff：ff：ff：ff：ff：ff：ff：ff

2) 环回测试已成功配置。
♯/usr/bin/mdio-tool-ext.sh w Ethernet1 0x0016 0xd004

3) 接收的数据字节数和接收的错误数据字节数都是零。 这很奇怪。
♯/usr/bin/mdio-tool-ext.sh r Ethernet1 0x0071
0x0000
♯/usr/bin/mdio-tool-ext.sh r Ethernet1 0x0072
0x0000

--mdio-tool-ext.sh 的内容--

#!/bin/sh

rw=$1
interface=$2
addr=$3
data=$4

/usr/bin/mdio-tool w $interface 0x0d 0x1f
/usr/bin/mdio-tool w $interface 0x0e $addr
/usr/bin/mdio-tool w $interface 0x0d 0x401f
/usr/bin/mdio-tool $rw $interface 0x0e $data

您好：

遗憾的是、您所做的环回测试（PCS，数字，模拟）都是面向 MAC 的环回、我们希望隔离 MDI。在这种情况下、需要反向环回。 方法是监测 PHY 上的链路（寄存器 0x1）和错误（寄存器 0x15）、同时查看 MAC1 上接收到的错误。 这将指示 PHY1 和 MAC1 之间的 MDI 或 MII 是否损坏。 这将能够隔离问题的潜在来源、因为目前没有已知的可疑对象。

MAC1 <->PHY1 <->PHY2（反向环回）

此致、
Gerome

您好 Gerome、

不幸的是、您所做的环回测试（PC，数字，模拟）都是面向 MAC 的环回、我们希望隔离 MDI。

如您所说、这些环回返回到 MAC 端、因此它们会检查 PHY 发送的数据包是否有任何问题。
因此、我们使用它们来检查 PHY 在出现 PHY 挂起问题后是否可以正常传输。
这就是我们之前的电子邮件征求您意见的原因。 请回复。

在这种情况下、需要反向环回。 方法是监测 PHY 上的链路（寄存器 0x1）和错误（寄存器 0x15）、同时查看 MAC1 上接收到的错误。 这将指示 PHY1 和 MAC1 之间的 MDI 或 MII 是否损坏。 这将能够确定问题可能来自何处、因为目前没有已知的可疑问题。

如您所说、研究 PHY 接收挂起的一个好方法是对 PHY 接收的数据包反向环回。
最好由 PHY 的链路伙伴监控环回数据包并观察导致挂起的有问题数据包。
遗憾的是、即使 PHY 循环回从 MDI 接收到的有问题的数据包、也无法观察到、因为 L2SW 没有监控功能。
由于 L2SW 没有用于 VLAN 配置的控制台、因此无法监控 L2SW 端口发送和接收的数据包。
如果您有任何好的想法、请告诉我。

此致、

ITO

您好、Ito、

应该有用于 MAC 分析传入流量的基本功能。 如果出现 RX 错误、则 MAC1 在反向环回配置期间检查就足够了。  

由于没有受控方法来检测链路断开、检查信号链的信号完整性只是其他运行状况检查、我们可以执行这些检查来清除 PHY 中的任何问题。

此致、

Gerome

您好 Gerome、

感谢您的答复。
但是、如果没有基于以下文档的具体建议、我将无法继续进行：
https://www.ti.com/lit/ds/symlink/dp83867cs.pdf

应该有 MAC 分析传入流量的基本功能。 如果出现 RX 错误、则 MAC1 在反向环回配置期间检查就足够了。  [/报价]

我们是否应该在 AM6442 原型上配置反向环回并重现该问题？
我们如何检查接收错误？

由于没有受控方法来检测链路丢弃、检查信号链的信号完整性只是其他运行状况检查、我们可以执行这些检查来清除 PHY 中的任何问题。

提到链路断开、您是指 PHY 挂起吗？
“检查信号链的信号完整性“究竟是什么意思？

此致、

ITO

[/quote]

您好：

从 PHY 的角度来看、只需配置为反向环回（通过寄存器 0x16）。 其余工作需要在 MAC 上完成。 由于这是 PHY 论坛、因此需要联系 MAC 专家。 如果需要、我可以重新分配。

关于 PHY 挂起、可能有多种原因。 链路丢弃是 PHY 上的一种特定状态、 可能会导致“PHY 挂起“。

此致、

Gerome

您好 Gerome、

感谢您的答复。
不过、我们觉得我们对这件事的调查又重新开始了。
我们打算通过您联系 TI 的技术支持人员、而不是亲自与您联系。
当然,我们假设以太网通信技术人员将在内部合作,为我们提供答案。我们希望咨询日本分公司的支持人员,并决定如何继续。
因此、现在让我们来结束这个问题。

此致、

ITO

尊敬的 Ito-San：  

请随时更新我们。  

此致、
j