LAN port disappears after reboot on NanoPi R4S #6342
Comments
|
I can confirm this. I just booted by Then I did an APT upgrade: And a DietPi update, and after reboot, I first thought the change in So if the DietPi update is not responsible, only left are the 4 APT packages, but those look all so completely unrelated. EDIT2: Now testing power cycle: Indeed both Ethernet devices are there again. Comparing kernel errors: root@NanoPiR4S:~# dmesg -l 0,1,2,3
[ 3.155277] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speedAfter reboot: root@NanoPiR4S:~# dmesg -l 0,1,2,3
[ 2.368851] mmc1: tuning execution failed: -5
[ 2.369250] mmc1: error -5 whilst initialising SD card
[ 2.502565] mmc1: tuning execution failed: -5
[ 2.657043] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[ 3.551691] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speedInterestingly no Ethernet related error added, but it boots differently after soft reset. |
MichaIng
added
Kernel related 🧬
External bug 🐞
|
Okay a kernel issue: Upgrading to "edge" solves it: apt install linux-{image,dtb}-edge-rockchip64Should become "current" soon. |
MichaIng
added
the
Workaround available 🆗
This did not fix it for me, still the same. This was on a fresh Dietpi install and here's my output for the kernel update |
|
Strange, it worked for me for quite a bunch of reboots. I turned off the device for a while, not back on and indeed with edge kernel it same issue now. I also see again the same kernel errors. No idea how it is possible that it went well the whole session after the kernel upgrade (the kernel errors were also gone after reboot). EDIT: After playing a little around, it now works fine again, both Ethernet devices there after (soft) |
MichaIng
removed
the
Workaround available 🆗
|
It appears that the issue is related to Armbian kernel bug, which has been reported over a year ago but remains unresolved. For reference, you can find the details of the problem at https://armbian.atlassian.net/browse/AR-1176 |
|
The apt install armbian-firmware-fullIt installs additional firmware, and it seems one of them is required for one of the R4S onboard NICs. |
|
The v8.21.1 update did NOT fix the main issue of this thread, nor did installing the full firmware. But I've encountered some other issues related to the update. The first issue is probably somehow related. As mentioned before my model has a chip with fixed MAC addresses for the 2 NICs, but since the update to v8.21.1 I've got a new random MAC for eth0 (eth1 has the correct MAC) after each power cycle. The other issue is related to the 4 LEDs on the device, the settings for LED control only shows 3 LEDs, LAN, WAN and Power and are set to none by default. This results in solid red light for Power, solid green light for the SYS and LAN/WAN always off. On previous versions this was solid red light for Power, heartbeat for SYS and LAN/WAN was network throughput. I have encountered this on my main installation AND on a fresh SD card with v8.16.2, which updated itself on the first login to v8.21.1. The first boot on v8.16.2 did NOT have the issue with the LEDs nor the random MAC address. |
|
Hmm, I did not recognise the broken LAN/WAN LEDs. Will have a look into it. Probably the nodes changes their names in There is the There are also ways to set it in userland via |
- NanoPi R4S | Resolved a v8.20 regression where the Ethernet LEDs did not react correctly after the kernel upgrade. Many thanks to @idaanx for reporting this issue: #6342 (comment)
|
Okay, the LED node names indeed have changed. I fixed the WAN and LAN LEDs: bdde5bd The 3rd one is falsely labelled. It is named as if it was the red PWR LED, but it actually toggles the green SYS LED, while the PWR LED has no node anymore. However, you can set the SYS LED back to heartbeat or activity or so. Not sure if we should override the kernel default? When I find time I'll see if I find a device tree patch to fix the SYS LED label and re-add a PWR LED node (if it was ever there?). About the Ethernet port disappearing: It still works find here with a warmed up device. I'll again power it off for a while and see if I can again reproduce it after it cooled down, like previously. What I forgot about the firmware fix, you likely need to rebuild the initramfs as well for it to take effect: update-initramfs -u
reboot |
|
Okay, installing the full firmware and updating the initramfs indeed does not solve it. I guess Igor just fall into the same trap that it does work well after the SBC has heated up a little. Kernel errors have changed a little with the new kernel. Aside of some unrelated thermal zone errors: The Ethernet error has gone. One reboot earlier I additionally got: After doing a benchmark and a minute stress test, oh and with overclocking overlay (which does now work!) to 2 GHz, it now works, with a steady 33 °C CPU temperature. It takes a while until the case has heated up as well to keep this steady. And again all above error messages are gone as well. What a strange hardware 😄. @idaanx |
|
I haven't used the Nanopi R4S for a while because of the issues. The last few weeks I've tried again to see if things have changed, using various distros / kernels. Dietpi 8.25.1 (kernel 6.1.63) still the same issues
Armbian 32.11.2 (kernel 6.1.68 or 6.6.2)
Armbian 32.11.2 (kernel 5.15.93)
FriendARM Debian Bullseye Core (kernel 6.1.53)
It works in Armbian, shouldn't it work in Dietpi too? Maybe it's not a kernel issue but the assignment of the mac addresses that goes wrong. Like I said before, my model has a chip with hardcoded mac addresses see standard vs. enterprise version. Which one do you have to test? Hope this helps solving this issue, if you need me to test something let me know. |
|
Probably it has been fixed recently between Linux 6.1.63 and 6.1.68. Armbian does not upload new kernel releases to the APT repo quickly. I'm currently building the latest kernel package: https://github.com/MichaIng/DietPi/actions/runs/7586686466 As of the MAC address: This might be unrelated. One thing to test: Update the bootloader via |
|
The new kernel (6.6.12) has fixed the issue of eth0 disappearing. The mac address is still randomised and adding it to the dietpieEnv.txt file didn't work. What worked was adding it to the /etc/network/interfaces file, not sure if this will survive an update or how to add it to /etc/network/interfaces.d. Maybe an option to add it to the dietpi-config? Also the WAN/eth1 still does not work, how can I get this working? |
|
Oh, great to hear. I wasn't aware that the "current" kernel is Linux 6.6 already. Probably we should install this kernel on all R4S systems with next DietPi version. Just tested it here. Sadly the RTL8811CU driver changed and seems to have issues now. It still works, but SSH connection seems choppy: I just built the new firmware package as well: https://dietpi.com/downloads/binaries/testing/ To enable the 2nd Ethernet interface, e.g.: cat << '_EOF_' > /etc/network/interfaces.d/eth1.conf
allow-hotplug eth1
iface eth1 inet static
address 192.168.1.2/24
_EOF_
ifup eth1Just an example with a static IP assigned and no gateway. This actually better suites for the LAN-side interface, while for the WAN interface, one usually wants DHCP? ifdown eth1
cat << '_EOF_' > /etc/network/interfaces.d/eth1.conf
allow-hotplug eth1
iface eth1 inet dhcp
_EOF_
ifup eth1Something like that. |
|
It's been a few weeks (just before new years) when I tested Armbian and at the time the default kernel was still 6.1.x. The 6.6.x kernel was a manual install, but since they are both LTS it doesn't really matter as long as it works. Haven't noticed any choppiness with the ssh connection during testing on my end. Got eth1 working and added another for eth0 to not override the mac address through dietpi-config. I have my DHCP handing out the static IPs so no need for it in Dietpi. |
It was only the firmware missing for the new driver for my particular WiFi chip. Solved with the new firmware package.
In case |
MichaIng
added
Solution available 🥂
|
New R4S images are shipped with the new kernel, and next DietPi update will install it as well: 149a797 |
Creating a bug report/issue
Required Information
Linux 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/LinuxSteps to reproduce
Expected behaviour
Actual behaviour
A power reset gets it back running again.
Extra details
This SBC doesn't have a HDMI-out but I've got in after rebooting through a serial connection and I've run the
ip acommand.Only eth0 is shown but has the MAC address of eth1/WAN.
This is how it looks on a normal boot.
My R4S should has a special chip which has the 2 MAC addresses stored in it, there is also a version without this see https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4S#Differences_Between_R4S_Standard_Version_.26_R4S_Enterprise_Version. Not sure if this might have something to do with this issue.
A cold boot also does not get an IP when connecting via the WAN port, not sure if that is as intended when not using the device as a router. Using the LAN port, rebooting and quickly switching the connection to the WAN port get it connected again, although this is not very useful.
The text was updated successfully, but these errors were encountered: