记一次网络丢包问题排查
初次收到的问题反馈为：部分机器（一半）丢包比较严重。
开玩笑？我这个PHY调过的，测过丢包和高低温的，怎么可能有问题！
1、替换法排查
- 测试新产的机器，所谓不丢包的机器我测的时候也丢包。
- 拿我手上以前留下来的自己用的裸板进行丢包测试，正常，基本上不丢包。
- 拿我手上的网络板替换机器上的网络板，丢包——排除网络板的问题。
- 拿我手上的主板替换机器上的主板，不丢包——主板问题。
2、常规排查
- 排查PHY部分电路的几个电源电压、纹波情况
- 排查PHY部分电路的上电时序
- 排查RGMII信号质量
由于上面替换法排除了PHY部分电路的问题，这几个可以不用查，直接查主板问题。（应不是干硬件的领导的要求，还是测了这些信号🙃）
主板差异点在于主芯片不一样，我手上使用的是zynq 的zu1，新生产的是zu5。排查ZU1和ZU5的主板电源和上电时序有没有差异（由于领导猜测zu5是不是比zu1娇贵一点，要求排查主板电源电压、纹波、上电时序🙃）。电源和时序均正常。
3、合理猜测
- ZU5和ZU1使用的是同一套代码，只是软件配置需要改一下型号。由于PL出现过编译失败的情况，怀疑是不是编译过程有问题，遂重新编译测试——未解决
- 无关PHY，那就查PL到PS之间的数据，查到中断异常，一个中断触发了PS多次中断
- 排查PL输出的中断，PL在线查和引出管脚后用示波器转中断信号，均未发现中断时间间隔明显拉长或缩短或连续触发的情况
PS中断异常，找不到原因
4、意外发现
某次瞎几把测试的过程中： PL：把网口重启一下看看？那个命令怎么写来着？ PS：ifconfig eth0 down和ifconfig eth0 up PL：ifconfig eth0 down ，回车！ 我：诶！不对，我们连的ssh……
好了，这下网卡起不来了，网口都down了，连不上了，只能插串口了，劈里啪啦找串口插上。
PL：这打印的什么东西？怎么上位机显示丢包的时候就打印这个？ PS：我没动这块代码啊？ 我：换zu1的板子看看
……
ZU1没这个打印，同一套代码，在ZU1上正常，在ZU5上有打印，打印信息为检测SD卡。于是设备树直接禁用SD卡，麻溜的编了一版刷进去，果然没丢包了。
结论就是这个检测SD卡的中断影响到了PS那边的中断，PS接收的数据并不是丢包，只是中断号重复了，以为丢了一个周期的包，最终表现在了上位机检测网络包时认为是丢包。至于为什么同一套代码ZU1和ZU5的表现不一致，那鬼知道。
