Figure

1）已经对log进行了分析，发现第497次ethernet底层驱动未进行连接的情况。
2）请帮忙复现该故障。@刘强

目前使用客户测得vb user版本压测36次，未复现异常：
验证步骤：

前提：先push升级包到中控
验证步骤：
1. 先在中控执行：ping 192.168.8.16 ，
如果能ping通，那么开始执行下一步升级；检查升级分区，slot_a 或slot_b
如果不能ping通，抓日志跳出，等待分析

2. 在能ping通的情况下，中控执行：./data/ota_mgr_fse_client uds_client 0xe80 0x1052 0xe400 192.168.8.16 /data/FSE_update.zip /data/ota/images.zip
触发升级

3. 等待15分钟，等副屏,升级成功后重启，再次检查升级分区，slot_a 或slot_b
如果step1 和step3 的分区不一致，则证明升级成功

4. 开始循环：1.检查ping通否，2.触发升级，3，确认升级成功

现有日志中，第497次，出现了有线网络连接线的频繁连接和断连，之后一直断连(这种连接和断连，是芯片硬件寄存器级别的，驱动能干预的可能性很小)。
当有线网络的连接一直不正常时，dtc_eth每隔5S打印1次日志。
01-01 18:53:22.706
#dtc_eth显示中间一直断开的日志
01-01 18:53:48.305 0 0 E DTC_ETH,link_delay_work_func: 3003, SQI=0, link=0
01-01 18:53:53.426 以下，全部同上
01-01 18:53:58.545
01-01 18:54:13.906
01-01 18:54:24.145
01-01 18:54:39.506
01-01 18:54:44.626
#dtc_eth显示后面一直断连

可以先等等刘强那边EVT1的测试结果。我的一些测试想法。
客户那边是使用的压测工具嘛，很容易进行测试吗？
1）同样软硬件(某版本VB+EVT1)条件下，客户那边再次复现故障是，FOTA多少次？ #是不是偶现，还是有规律复现
2）客户使用另一块EVT1电路板是什么情况？如复现，继续。 #是不是硬件个体差异
3）客户更换一条网络连接线，是什么情况？如复现，继续。 #是不是网线
4）客户使用EVT2电路板是什么情况。 #是不是EVT1和EVT2上有线网络部分硬件电路上的不同

还有一个可能的点没有考虑， 有没有可能是主控那边的问题，毕竟连接是2方的事情。

客户回复：
问题一：可以更换硬件，换成VC1的测试，@封得财 手中有VC1提供吗，自研这边还没领到
问题二：是贵司去确认是否为单板问题
问题三：使用的是标准网线

客户周末压测94次复现网络不能ping通的现象，副屏控制器不变，换了一个中控还是无法ping通。日志已上传。FSE-M_tlog.zip

经过上周末的多轮测试，OTA故障已经复现。
使用独立电源，未与中控共用电源的情况下；即之前怀疑的是由于共用电源问题造成的故障的可能性，很小了。
现在做的第一步是，使用0402日DB的userdebug版本，进行OTA测试，看能否复现故障。以方便接下来的调试工作。

1)已经同步提交了高通case。
2）排除1个疑点：在中控端，发现了警告“2022-11-11 10:49:26 base WARN ix_platform.c 75: !!!this is not root permission, can not set the priorirty”，通过在中控端加root权限，将此警告去除。排除了是中控权限的问题。
3）目前正在积极排除，是emac驱动的问题还是phy芯片的问题。

1）客户提供了vlan的配置信息。./system/etc/HHTEthernetConfig.sh正在使用验证。
2）客户提供了这个信息，。需要测试一下。
ssh root@223.255.255.1，进入QNX
你看看这个行不行
eth0不知道是不是这个口
pth_eth mode set 2 0x1，是设置 port 2 为 master
pth_eth mode set 1 0x0，是设置 port 1 为 slave

3）在文档https://thundersoft.feishu.cn/docx/GVsXdxMJMo3dQexYxXBcqygvnuQ 中有最新的探索，但受限客户支持，尝试多失败。

中控与中控之间的网速测试已经实现了，详细见共享文档的“第三步 网速测试”。
说明了中控与中控的TCP传输，同样存在重传现象，需要中控的人员自己去解决。
按照@陶洪普 的建议，接下来，我方会转向到网卡为何会中断这一点上来。

祥林和洪普向我提出的追踪建议：
1.中控与中控的TCP传输，同样存在重传现象，需要中控调查一下。
2.中控与副屏的OTA丢包问题，调查方向：
a.MTU值影响数据包的传输正确性和传输延迟。尝试修改MTU值看看是否有改善。
b.TCP缓冲区满影响数据包接收。尝试修改缓冲区大小。
3.OTA后网络断开的问题，调查方向：
a.打开mac控制器的调试信息功能，通过查看传输失败的时候日志来定位。
b.继续进行副屏之间的OTA压测，看看断网是否和丢包重传有必然联系。
c.提case找高通支持。
针对此，我做了如下测试
2.a 已尝试修改双边的MTU值均为1490，无改善，TCP过程中依然有重传；
2.b TCP缓冲区空间已经改大，并且观察到TCP窗口还有很大空间，无改善，TCP过程中依然有重传；
3.a 首先需要解决的问题是日志的获取，试图通过tlog获取，但由于内核信息时间与板上时间无法对齐，没法使用。尝试修改脚本，如何z在故障发生过程中将dmesg信息保存下来。
3.b 进行fsme间的压测，偶尔能复现，但明显感觉概率低了很多。
3.c 已经寻求高通case支持，但是由于有线网络外设为该平台上的自加外设，高通这边支持深度不确定。

周六，继续对故障现象进行追踪，发现phy寄存器的控制模式寄存器0x8034异常，phydev->speed异常，对控制模式寄存器0x8034修改值为正常值后，电路板基本能回复正常。
现在正在添加debug，查找可能修改“控制模式寄存器0x8034”的地方进行追踪。
但由于复现故障很困难，时长不定，因此进展不快。

针对故障现象的分析，与总结：
1）通过对故障现象的多次研究，发现phy芯片的模式寄存器值被改变了，经过尝试，将其值修改回去后，发现网络能够正常工作了；
2）通过添加调试信息，经过几次故障发生时dmesg信息的抓取，推断可能是1s一次的读取phy芯片的模式寄存器(找不到有对该寄存器的更改位置)，造成了该寄存器的值被改变。
3）现进一步推测，由于读取phy芯片的模式寄存器共分成了3写1读来完成，当还有其他读取phy芯片寄存器的操作时(DTC操作，读取sqi、link寄存器状态)，就可能发生操作叠加。正计划，对读取phy芯片寄存器的操作进行上lock操作。

1）根据刘强的测试结果和自测的结果，基本确定了故障原因为phy模式寄存器在1s1次查询的过程中，与DTC_ETH的寄存器访问线程产生交叉效果，造成了phy模式寄存器被改变成了0x8009。

2）现已根据这一故障原因，生成了patch，检测后，逻辑应为正常，待VB后，进行多方的连续测试，直到不出现故障为止。

客户针对刘强反馈的：144次没有出现网络不通的情况，但是期间有10次升级失败，进行了客户端程序调整（传包增加了延时处理），目前测试68次，没复现故障。