phicomm-n1
phicomm-n1 copied to clipboard
yangxuan8282
所有断网问题发到这里
要求按照格式发：
- 发行版及版本号，比如 Armbian_5.67_Aml-s9xxx_Debian_stretch_default_4.19.7_20181218
- 所用 dtb 的链接及 md5sum
- 什么情况下出现断网，必须给出细节，比如开机多久之后出现，或者在传输多大文件，再或者运行某应用时候出现，要求能复现，以及具体症状是什么，比如 ping 不通还是延迟高还是其它
不按照格式或者未给出何种情况出现断网的不予答复
另外诸如某些无依据的推测不要再出现，比如断网是由 network manager 引起这种
N1 的网卡是 RTL8211F，这个网卡的问题由来已久，在 2016 年就有人发现并提交了 patches 来解决断网问题： https://patchwork.kernel.org/patch/9429911/
所以很长一段时间内包括 odroid c2 这种采用 RTL8211F 的设备需要禁用 EEE 来使得网络稳定，也即在 dts 中添加 eee-broken-1000t;
( mailing list 中也有用户提出可以将网卡最大速度限制在 100M 来保证网络的稳定 )
而发生这种情况的原因在最近有了答案，一位内核开发者发现是之前一处错误的定义导致了这种情况，并修正了这个问题： https://patchwork.kernel.org/cover/10712163/
在这之后采用 RTL8211F 的设备应当不需要禁用 EEE 即可保证网络稳定，相关更改已被合并进入主线 ( https://github.com/torvalds/linux/commit/8b3e6f8999f8d704fccce225b9455b3fa639d1c9 ) ，出现在 5.0 ( 本来应该是 4.21 ) ，也就是说在你使用 5.0 内核之后应当无需禁用 EEE 了
至于老版本内核，比如 4.18 或 4.19，在修正错误的定义之后也应该不会再受开启 EEE 所带来网络问题的困扰，本身这个更改只是 device tree 中的，所以只需重新编译 dtb 即可
dtb文件补丁操作，都是dtb复制到u盘BOOT区的dtb目录下，同时修改uEnv.ini和extlinux\extlinux.conf文件改成引用meson-gxl-s905d-phicomm-n1.dtb，然后u盘引导后./install.sh安装到N1，halt再断电拔u盘再上电开机，以上操作是否正确？若有误请指指导下，谢谢！
Armbian_5.62_Aml-s9xxx_Debian_stretch_default_4.18.7_20181012.img meson-gxl-s905d-phicomm-n1.dtb.DA70B624E4349333F3656ECC381488A9 这套192.168.2.3执行 iperf3 -u -c 192.168.2.4 -b 1000M -i 1 -w 1M -t 60000
Armbian_5.68_Aml-s9xxx_Debian_stretch_default_4.19.13_20190110.img meson-gxl-s905d-phicomm-n1.dtb.232907334E89058458D2ED6FB1773B61 这套192.168.2.4执行 iperf3 -s
跑iperf之前，从win10PC 192.168.2.148刚开始复制100多G的电影到192.168.2.4（omv_smb共享移动硬盘），然后192.168.2.3执行 iperf3 -u -c 192.168.2.4 -b 1000M -i 1 -w 1M -t 60000测试跑了一夜60000跑了超过一半多，网络仍然很好，于是就停了；
然后陆续复制其他电影到192.168.2.4，同时网页查看192.168.2.4上netdata网页报表，各个图标曲线瞎看看……然后不经意间发现从从win10PC 192.168.2.148操作，拷贝192.168.2.4上1G左右的各类壁纸图片到192.168.2.3时候，复制进度停滞了，此时发现192.168.2.4 ssh操作卡的要命，192.168.2.4 netdata刷新缓慢，从192.168.2.3 ping 192.168.2.4 延迟几百几千几万毫秒，192.168.2.4 ssh操作虽卡仍能勉强完成sudo reboot （键盘操作后需要等待几秒十几秒才看到相应显示）
192.168.2.4 重启后网络操作反应恢复了，包括拷贝192.168.2.4上1G左右的各类壁纸图片到192.168.2.3时候也顺利完成，网络卡的表现用户端就是这样的，不会log挖掘，但现在能看到netdata上图表，需要关注哪块才能找到原因？
看了下netdata网页报表上的log ，红色警告状态log 这个片刻有这么一些log
下午1:41:38 | ipv4.tcphandshake | 10s ipv4 tcp resets received | 0 tcp resets/s | CLEAR 下午1:41:38 | ipv4.tcphandshake | 1m ipv4 tcp resets received | 0 tcp resets/s | UNDEFINED 下午1:41:38 | ipv4.tcphandshake | 10s ipv4 tcp resets sent | 0.1 tcp resets/s | CLEAR 下午1:41:38 | ipv4.tcphandshake | 1m ipv4 tcp resets sent | 0.19 tcp resets/s | UNDEFINED 下午1:41:38 | ipv4.tcphandshake | ipv4 tcphandshake last collected secs | 00:00:01 ago | CLEAR 下午1:41:38 | system.ram | ram in use | 21.1% | CLEAR 下午1:41:38 | ipv4.udperrors | 1m ipv4 udp send buffer errors | 0 errors | CLEAR 下午1:41:38 | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 0 errors | CLEAR 下午1:41:38 | ipv4.udperrors | ipv4 udperrors last collected secs | 00:00:01 ago | CLEAR 下午1:41:38 | system.softnet_stat | 10min netdev budget ran outs | 1116 events | WARNING 下午1:41:38 | system.softnet_stat | 10min netdev backlog exceeded | 0 packets | CLEAR 下午1:41:38 | system.ipc_semaphore_arrays | semaphore arrays used | 0.0031% | CLEAR 下午1:41:38 | system.ipc_semaphores | semaphores used | 0% | CLEAR
当时应该正在复制各类壁纸照片，然后发觉“网络卡死了”
还有这么几条
| 1:35:35 PM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 252 errors | CRITICAL |
|---|---|---|---|---|
| 1:34:45 PM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 1 errors | WARNING |
再之前 11:47:15 AM | net_packets.eth0 | 10s received packets storm | 2023% | CRITICAL …… 10:24:55 AM | system.softnet_stat | 10min netdev budget ran outs | 65876 events | WARNING …… 当时具体操作应该是从win10PC 192.168.2.148 操作整理192.168.2.4（omv_smb共享移动硬盘）上的共享
iperf跑流量始终有持续的ipv4.udperrors，且此期间netdata的alarm只记录了ipv4.udperrors没有其他net_packets.eth0和system.softnet_stat 10:12:03 AM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 103 errors | CRITICAL 10:16:13 AM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 87 errors | WARNING …… 1:08:13 AM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 1420 errors | CRITICAL 1:08:03 AM | ipv4.udperrors | 1m ipv4 udp receive buffer errors | 40 errors | WARNING
解决了
https://github.com/yangxuan8282/phicomm-n1/issues/15#issuecomment-456116693
目前 150balbes 的内核仓库中已经打了上游的修复补丁，修正了定义，之后应该不需要禁用 eee 了
之前给 mainline 提交的 N1 device tree 是引用了 meson-gxl-s905d-p230.dts，在此基础上禁用了 cvbs，网络部分没用单独做修改 ( 禁用 eee 当时是更改在 p230 的 dts 上 )
而到 5.0 内核( 现在的 next 镜像里其实已经有了 ) 会有 n1 的 device tree，直接修改 uEnv.ini 就能使用
有现成镜像： https://yadi.sk/d/srrtn6kpnsKz2/Linux/ARMBIAN/5.72/S905/NEXT
uEnv.ini 和以前一样，还是将 dtb_name=/dtb/meson-gxl-s905x-khadas-vim.dtb 更改为 dtb_name=/dtb/meson-gxl-s905d-phicomm-n1.dtb
使用yangxuan8282提供的4.18 dtb，正常使用挂PT每天发送300G流量左右，使用半年只出现过一次断网。
使用iperf测试发送，测试多次千M跑5分钟到30分钟不等断网，断网前无减速，直接就没网了，断网后网卡显示正常，IP显示正常，路由显示正常，内核及systemd无任何日志，需重启系统才有网络。
但是同样dtb使用iperf接收测试1小时以上无断网情况。
使用cattyhouse提供的4.19 dtb，使用iperf发送3个小时1个多T流量无断网情况，断网的问题貌似和禁用eee无关，https://patchwork.kernel.org/patch/10712159/ 才是最终解决方案。
