schwar3kat Posted May 30, 2022 Posted May 30, 2022 'ethtool -K lan0 tx off' mitigates the issue. modifying /etc/udev/rules.d/70-rename-lan.rule to 'SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth1", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off"' mitigates the issue permanently. But if you plug in another usb ethernet adaptor, it changes the name of the of the interface from lan0 to enx8aaf6680410a and the rename in /etc/udev/rules.d/70-rename-lan.rules no longer works, so lan0 is not consistent. Maybe we should leave it like this as a known issue with instructions on how to mitigate the issue, and I can investigate further and see if we can improve it for next release.
Igor Posted May 30, 2022 Author Posted May 30, 2022 29 minutes ago, schwar3kat said: Maybe we should leave it like this as a known issue with instructions on how to mitigate the issue Yes, that is perfect way. Just add those few lines to the download pages. Forum is kind of a black hole for this. Yes, this can wait for next release. If there will be a lot troubles in general, we might also come out with some bugfix release earlier. So far things looks good so this scenario is less likely to happen.
schwar3kat Posted May 30, 2022 Posted May 30, 2022 I think that I figured a way to patch this in that will work for all scenarios. Just need to test. Nope: scrap that. I added a few lines to the download page. @Igor What state should I leave the Jira -AR1204. Currently it's 'to do' and tagged for this release and has a comment about the added lines.
Igor Posted May 30, 2022 Author Posted May 30, 2022 3 hours ago, schwar3kat said: What state should I leave the Jira -AR1204 Bug closed with a workaround - text on download pages is good enough. I would propose to open a task for its integration and integrate when possible, with normal priority.
schwar3kat Posted May 30, 2022 Posted May 30, 2022 @Igor I have found a simple way to apply the mitigation that will work for most scenarios. It will continue to work with most external plugin USB NIC's that change the kernel NIC names (the previous work around would fail). The only scenario where it may not work is if a plugin NIC that requires the same r8152 driver is used. /etc/udev/rules.d/70-rename-lan.rules is modified using "eth*" as follows: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth*", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off" This will find the NIC with driver r8152 and rename it to lan0 then apply "tx off" to lan0. The affected boards ( nanopi-r2s and r2c, and orangepi-r1plus and lts) already grouped have a routine to create the file '70-rename-lan.rules' in config/sources/families/include/rockchip64_common.inc (to rename the NIC to lan0) and this is trivial to modify. . I have tested the change built on my local branch on orangepi-r1plus-lts. Orangepi-r1plus doesn't have a maintainer. You are maintainer of the others. I know that you don't have a r2c, but perhaps you have a r2s (forum indicates it has the bug)? If it is acceptable to patch for the 4 boards then I can have a PR ready very soon. I have not yet opened a new Jira task, in case a sub-task on AR1204 might be appropriate. This is more of a work around than a fix, but it will have to do until we can find a better solution.
schwar3kat Posted June 6, 2022 Posted June 6, 2022 On 5/30/2022 at 10:36 PM, Igor said: text on download pages is good enough It has been diabolically difficult to identify this issue. Good news is that it is not a build issue, and it's not a reversion of the lan0 bug. I have flashed around 100 images and done countless power-downs and reboots. Each time I thought that I was making progress, more testing disproved it. The initial workaround did seem to resolve the issues, but they still occur if enough reboots are done. Even older builds have the issue if enough reboots are done. It seems that newer builds are just more sensitive to the issue. At one point I thought that there were two different issues for Debian and Ubuntu builds because the fixes were different, but more testing proved that the fixes didn't stick permanently. Symptoms are also variable, from the more common intermittent drop-outs and slow-downs to the less common total loss of lan0 NIC or total loss of networking. In my environment, the issues can be completely eliminated by disabling IPv6. Using armbian-config to do this does not work! The armbian-config method adds lines to /etc/sysctl.conf but unfortunately this does not disable IPv6. Ipv6 must be disabled by adding extraargs="ipv6.disable=1" to armbianEnv.txt. The cause seems like it might be related to the resolvconf-pull-resolved.service and NetworkManager and RTL8153B, and is intermittent, but once it has stopped working correctly, it is problematic to get it working again without a power-down (on Ubuntu, apt-get --reinstall install resolvconf then reboot fixes it temporarily). I suspect that my IPv4 NAT environment is sometimes confusing resolvconf or some other networking component on this board and leaving somethings in networking in a corrupt state. I don't have the same issue with my H5 and H3 boards. I will change the work-around instructions to reflect my findings. 2
Igor Posted June 7, 2022 Author Posted June 7, 2022 @Contributor/Maintainer Certain issues has been reported, we know some images are corrupted due to CI issues. Planned package changes for (v22.05.2) will be BSP, U-boot, but we can probably also update all kernels if we are confident enough and if smoke tests will go trough? DUE in about a week.
Igor Posted June 22, 2022 Author Posted June 22, 2022 @Contributor/Maintainer Updates on legacy / current kernels (where only a patch version is changed) and u-boot packages (many from Rockchip family are broken on current release / update is anyway optional) are going to repository today, images repack follows. Huge task ... 1
Igor Posted June 23, 2022 Author Posted June 23, 2022 Build done, none of the images is corrupted this time. The only change in runners setup is removal of dual 10Gb connection (Intel X710-AT2 in LACP bundle), which connection was unstable. Population to servers in progress for next couple of hours.
schwar3kat Posted June 24, 2022 Posted June 24, 2022 orangepi-r1plus-lts - all images are good Iperf speeds are as expected for both Ethernet interfaces. Tested: Armbian_22.05.3_Orangepi-r1plus-lts_bullseye_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_edge_5.18.0.img.xz Some of the Asia mirrors were 404. Guess the images are not there yet.
Igor Posted June 24, 2022 Author Posted June 24, 2022 5 hours ago, schwar3kat said: Tested: Armbian_22.05.3_Orangepi-r1plus-lts_bullseye_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_edge_5.18.0.img.xz Thanks! 5 hours ago, schwar3kat said: Some of the Asia mirrors were 404. Guess the images are not there yet. I have temporally disable those that are not in sync yet.
jock Posted June 25, 2022 Posted June 25, 2022 OrangePI 4 LTS, tested: Ubuntu Jammy CLI kernel v5.15 Ubuntu Jammy XFCE kernel v5.15 All seems right fine 👍
TRS-80 Posted August 1, 2022 Posted August 1, 2022 (edited) Sorry for again disappearing. It took up much more time and energy than I thought to find a new place (very tough market here) and get moved. On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)! Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now! Edited August 1, 2022 by TRS-80 punctuation 3
Recommended Posts