Frank F. Posted October 16, 2020 Posted October 16, 2020 I know it's not an officially supported board, but it's been working really well so far, so I'll give it a shot. Today I updated my kernel to 5.9.0-sunxi (coming from 5.9.0-rc7-sunxi) and after rebooting the (wired) network was dead. Everything looked fine, ethernet driver is loaded, interfaces were up and had IP addresses, but packets were not being sent. Pinging anything but the Banana Pi itself says "destination host unreachable". Routes were set and looked correct - even tho they should not even be necessary as I was pinging the gateway. tcpdump on eth0 showed nothing at all, almost as if the kernel doesn't know where to send the packets. Anyone else having the same problem or any ideas what else I could try? I did get the system back online by downgrading linux-image-dev-sunxi and linux-dtb-dev-sunxi, but that does not seem to me like a future proof solution.
Igor Posted October 17, 2020 Posted October 17, 2020 Apparently this commit is responsible - you are welcome to submit a patch with reverting this change or we all wait that this is properly addressed upstream. Ref: https://groups.google.com/g/linux-sunxi/c/RlwVRySBaUo
Frank F. Posted October 17, 2020 Author Posted October 17, 2020 That was quick. I was looking to submit a PR, but I think that this commit reverts the original "fix" already, correct? How do I find out if a new kernel package in the repo contains the commit?
Werner Posted October 17, 2020 Posted October 17, 2020 You can build a new kernel package from master branch using the build script. This will include @5kft's revert commit. Or you get lucky a find a matching package here: https://beta.armbian.com/ 1
guidol Posted October 17, 2020 Posted October 17, 2020 1 hour ago, Werner said: You can build a new kernel package from master branch using the build script. This will include @5kft's revert commit. I did it and it does work -rwxr--r-- 1 datashare datashare 43652 Oct 17 17:58 armbian-config_20.11.0-trunk_all.deb -rwxr--r-- 1 datashare datashare 6916332 Oct 17 17:58 armbian-firmware_20.11.0-trunk_all.deb -rwxr--r-- 1 datashare datashare 192712 Oct 17 17:57 linux-dtb-dev-sunxi_20.11.0-trunk_armhf.deb -rwxr--r-- 1 datashare datashare 35322316 Oct 17 17:58 linux-image-dev-sunxi_20.11.0-trunk_armhf.deb -rwxr--r-- 1 datashare datashare 236608 Oct 17 17:48 linux-u-boot-dev-bananapim2berry_20.11.0-trunk_armhf.deb ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \| __ ) | _ \| |_) | | | |\/| | __) | _ \ | |_) | __/| | | | | |/ __/| |_) | |____/|_| |_| |_| |_|_____|____/ Welcome to Armbian Buster with Linux 5.9.0-sunxi package bsp-kernel[20.11.0-trunk] u-boot[20.11.0-trunk] dtb [20.11.0-trunk] firmware [20.11.0-trunk] config[20.11.0-trunk] branch[dev] root@bpi-m2-berry(192.168.6.20):~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.20 netmask 255.255.255.0 broadcast 192.168.6.255 ether 02:53:bc:93:a8:02 txqueuelen 1000 (Ethernet) RX packets 329 bytes 35595 (34.7 KiB) RX errors 0 dropped 2 overruns 0 frame 0 TX packets 315 bytes 35070 (34.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 37 root@bpi-m2-berry(192.168.6.20):~# dmesg|grep eth0 [ 8.326164] dwmac-sun8i 1c50000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 8.329007] dwmac-sun8i 1c50000.ethernet eth0: No Safety Features support found [ 8.329028] dwmac-sun8i 1c50000.ethernet eth0: No MAC Management Counters available [ 8.329037] dwmac-sun8i 1c50000.ethernet eth0: PTP not supported by HW [ 8.329052] dwmac-sun8i 1c50000.ethernet eth0: configuring for phy/rgmii link mode [ 10.454163] dwmac-sun8i 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx 1
Solution Frank F. Posted October 18, 2020 Author Solution Posted October 18, 2020 I just installed 5.9.0 from the 20.08.12 package and I can confirm it's working fine. The system came back with working network connection. Thanks to everyone, esp. @Igor for finding the root cause and @5kft for getting the patch included so quickly. 2
5kft Posted October 24, 2020 Posted October 24, 2020 @Igor I'd like to get your thoughts regarding this...: The Realtek kernel change that caused this issue is indeed correct and good (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=bbc4d71d63549bcd003a430de18a72a742d8c91e), as it fixes the earlier invalid implementation in the kernel. The failure problems with the RTL8812E occur with this change because "phy-mode" in the DT now matters and must be correct, whereas previously it did not. By changing the "phy-mode" to "rgmii-id" correctly for sunxi boards that have the TXDLY and RXDLY pull-ups on the PHY, the RTL8812E is properly configured and works. However this means that all of the relevant DTs need to be updated to correctly reflect their actual hardware configuration. I started making these changes in the patches in sunxi-dev, confirming the existence of the delay configuration pull-ups with the board schematics to determine the proper phy-mode to set, and removing my reversion patch. However any boards that are missed will have Ethernet failures until the DTs are properly patched. Should we just leave the reversion patch in instead (long-term)? 1
Igor Posted October 25, 2020 Posted October 25, 2020 12 hours ago, 5kft said: However any boards that are missed will have Ethernet failures until the DTs are properly patched. Should we just leave the reversion patch in instead (long-term)? I would say we remove revert and go with a mainline. Also possible to just wait since most of them are already changed https://groups.google.com/g/linux-sunxi and remove our patch once they reaches maineline? 1
5kft Posted October 25, 2020 Posted October 25, 2020 1 hour ago, Igor said: I would say we remove revert and go with a mainline. Also possible to just wait since most of them are already changed https://groups.google.com/g/linux-sunxi and remove our patch once they reaches maineline? Yes, I agree - especially if this patch from @Icenowy makes it into the mainline: https://groups.google.com/g/linux-sunxi/c/QzBM7nciPLo. We should wait for the dust to settle then can remove our revert patch and adapt the other DTs appropriately. Thanks! 2
Recommended Posts