所有断网问题发到这里
yangxuan8282 opened this issue · comments
要求按照格式发:
- 发行版及版本号,比如 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 即可保证网络稳定,相关更改已被合并进入主线 ( torvalds/linux@8b3e6f8 ) ,出现在 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
解决了
目前 150balbes 的内核仓库中已经打了上游的修复补丁,修正了定义,之后应该不需要禁用 eee 了
之前给 mainline 提交的 N1 device tree 是引用了 meson-gxl-s905d-p230.dts
,在此基础上禁用了 cvbs,网络部分没用单独做修改 ( 禁用 eee 当时是更改在 p230 的 dts 上 )
而到 5.0 内核( 现在的 next 镜像里其实已经有了 ) 会有 n1 的 device tree,直接修改 uEnv.ini 就能使用
能否编译一个5.0的内核呢? 如果有了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/ 才是最终解决方案。