Heisath

Yeah maybe we have to contact Gregory Clement (the original author) on updates? I find no trace of this patch in any kernel after about 4.4 Maybe they figured it was broken and thus have not mainlined it?

You can build dev with ./compile.sh EXPERT=yes I assume he is referring to the series of patches we have for DFS support: https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/800-Add_Armada_38x_support_for_clk-cpu.patch https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/801-Use_shorter_register_definition_in_pmsu_c.patch https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/802-Made_the_dynamic_frequency_scaling_support_more_generic.patch https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/803-Armada_38x_Add_dynamic_frequency_scaling_support_in_pmsu.patch https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/804-Update_Armada_38x_DT_for_dynamic_frequency_scaling.patch These have been in there for a long time and might indeed cause the crashes. Probably they need to be adjusted (although they still apply fine).

So I figured it out (and wasted 5 hours or so ) ... Support for bridge flags for the mv88e6xxx chips was introduced here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/dsa/mv88e6xxx?h=v5.1&id=4f85901f0063e6f435125f8eb54d12e3108ab064 One of these flags is flooding. Which seems to be enabled by default, and leads to incoming packets on port A to be replayed on all other ports. This naturally lowers the receive speed on port A to the minimum transmit speed of all other ports. Easy way to fix this is to issue 'bridge link set dev lan4 flood off' for all the lan ports on the clearfog. I confirmed this also works on Lk5.8 Does it make sense to add a family tweak which does this for all lan ports? Or is this possible via device tree? EDIT: Nevermind, this is not an issue with the dsa but with the default settings of a linux bridge. Let's not touch it, because not everyone will put the lan ports on the clearfog in a bridge. If they do, they hopefully stumble upon this and check the man page: https://www.man7.org/linux/man-pages/man8/bridge.8.html

Okay is there an easy way to install? Then I might try it. I believe you on the kernel issue. Just thinking it might be a user space triggering a kernel issue issue.

Quick update: Kernel 5.0.21 is also working fine. 5.1-rc1 has the defect. So there's some regression between those. Still trying to narrow it down.

Hey, I am not sure if it is possible to select a kernelbranch by commit. Maybe someone else knows? May I ask what else you have installed, or if you have tried with a clean image? If there is no private data/configuration on you Helios4, you might also upload a image of your sd card so we can try with your config. I have been running a helios4 for nearly 2 days now, with no crashes. Transfering some data (~400GiB) with samba. Welcome to Armbian 20.11.0-trunk Buster with Linux 5.8.18-mvebu No end-user support: built from trunk System load: 12% Up time: 1 day 21:13 Memory usage: 4% of 1.97G IP: 192.168.42.127 CPU temp: 42°C Ambient temp: 28°C Usage of /: 6% of 29G storage/: 50% of 117G Last login: Sun Nov 22 08:53:30 2020 from 192.168.42.11 root@helios4:~# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.42.127 netmask 255.255.255.0 broadcast 192.168.42.255 inet6 fe80::bd05:f16:95a0:fee prefixlen 64 scopeid 0x20<link> inet6 2a03:4000:2b:63a:1098:42:0:1c1 prefixlen 128 scopeid 0x0<global> ether 0e:47:85:69:06:21 txqueuelen 1024 (Ethernet) RX packets 283087536 bytes 427927106434 (398.5 GiB) RX errors 61 dropped 0 overruns 0 frame 0 TX packets 24727708 bytes 1401262789 (1.3 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 37

You can check here for deb files: https://beta.armbian.com/pool/main/l/ and https://apt.armbian.com/pool/main/l/ There is not necessarily a release for every kernel version. But you can try your luck. Remember when changing kernel with dpkg to not only update image but also dtb. There are sometimes changes there. Apart from that between the different 4.19 version there is not much difference from armbian side.

@Mangix Just to make sure, your using github.com/armbian/build | master branch and build current version (5.8.y) and your helios4 freezes after 2-3 hours? Did you only build kernel files and change kernel or is this a clean/complete image? Can you tell us about your load on the helios4 during those times? Just idling? 2-3 hours should be easy enough to reproduce. I will take my build from yesterday (after merging your PR) and try with it. If possible can you test some more and leave a few of the patches you removed in there? Just to narrow it down. The Helios4 is not using PCI or SFP so it would be good to leave those in there for testing. The GPIO / timer patches are needed for PWM fan support. @FredK Do you also have such a high frequence of reboots?

Hello, I have discovered interesting behaviour of the clearfogpro switching between lk4.19 and 5.8 and would like to know if others are able to reproduce. And maybe have ideas on how to fix. Steps to reproduce: - have a clearfogpro - get the current armbian image https://archive.armbian.com/clearfogpro/archive/ 20.08 - 'apt update && apt full-upgrade' - set the lan1-6 interfaces to bridging (example via following /etc/network/interfaces : https://pastebin.com/dpXEBe6g ) - reboot - plug into your network should be GBit (on lan1-5). Verify you get ip, and can reach other devices. - run iperf3 between clearfogpro and other gbit device in your network. Should yield about 900MBit/s Now the interesting part: - attach another device to the switch - see how both status leds blink when transfering data via iperf3 ? The bridge seems to run as a hub and not a switch. - now plug a 100mbit/s device into the bridge. - test speed to a gbit device with iperf (both directions): one direction will only yield about 100mbit/s. - while iperf3 is running to the gbit device, unplug and replug the 100mbit/s device on the switch, you should see the rate jump between 100 and 1000..... NOTICE: This only happens in the direction where the clearfogpro is receiving data. Send speed is still at 1gbit/s. Now use armbian-config and switch to LK4.19, reproduce steps from above. You should only see one activity led blinking and the switch functioning correctly at 1gbit/s even with a 100mbit/s device connected. So this leads me to think there's either some difference in the handling of the clearfogpro switch chip (between LK4 and 5) or some difference in bridge package. It would be great if someone could confirm so I am sure, it is not a problem with my setup. root@clearfogpro:~# iperf3 -c 192.168.42.3 -t 100 -R Connecting to host 192.168.42.3, port 5201 Reverse mode, remote host 192.168.42.3 is sending [ 5] local 192.168.42.106 port 33648 connected to 192.168.42.3 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.3 MBytes 94.3 Mbits/sec # 100mbit/s device plugged into the switch [ 5] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 4.00-5.00 sec 26.7 MBytes 224 Mbits/sec # 100mbit/s device removed [ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec [ 5] 6.00-7.00 sec 105 MBytes 878 Mbits/sec [ 5] 7.00-8.00 sec 107 MBytes 893 Mbits/sec ^C[ 5] 8.00-8.61 sec 63.9 MBytes 885 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-8.61 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-8.61 sec 454 MBytes 443 Mbits/sec receiver

Compare with the current posts in this thread: Might be a common problem?

No problem. The features listed on the website get more or less compiled from https://docs.armbian.com/ and you can easily create a pull request on github for the documentation to get the USB-C issues listed. Once the issues are listed in the documentation someone (of the website admins) can update the feature list.

We don't have lists for each board & kernel configuration with all known issues & working features. Also not for every software there is (OMV, samba, ...). I am sorry you ran into these issues (they are normal in the SBC world I'd say). Would you help us by creating such lists? Just grab a significant amount of the boards on the download page, install the current armbian release and compile lists with features/problems for all software that is interesting. Maybe even create some google docs sheet? Kind regards, Heisath

Interesting thing: One more donator than donations:

I can't use the saved actions (probably because I'm not a moderator). I remember though, that I could use the canned replies. So for me this means more typing to point ppl to armbianmonitor etc.

I could imagine this weekends saturday night (saturday night in UTC so afternoon for Americans). Would try to get 5.9 for mvebu. Not sure if it is worth it to try squeezing all boards in. Depends on ppl. participating w/ testing.

Maybe check the device-manager for the actual name of the serial port? Might not be COM3 but COM1-12...

@FredK, the LED problem has been fixed in AR-491 [https://github.com/armbian/build/pull/2283]. They will work again with the next bugfix release and 20.11. Thanks for reporting the issue.

Hi FredK, The contradicting armbian version numbers are thing open to discussion. Basically armbian uses many packages and not all of them get updated everytime -> different version number exist. This is synced at every major release. The fact alone that the linux kernel 5.8 was released with 20.08.xx was a mistake on armbian side. Sorry for the problems we caused. If you can live with the LEDs not working a fix will be available at the latest for the 20.11 release (end of November). If you need the LEDs working now you can switch to kernel version 5.4.xx (via armbian-config, pick it by the kernel version on the right. Not the armbian version) there everything should work. ( I tested and can confirm the bug is not yet present in LK5.4.69). As said the release of 5.8 on 20.08.xx was a mistake. Sorry. Heisath

Hi FredK, I confirmed your problem. There seems to be some issue on the pin assignment of the LEDs. Can you tell us which kernel version you are using? (output of uname -a and/or armbianmonitor -u) As a quick fix you can go back to 20.08.13 or try to just downgrade the kernel via armbian-config. Regards, Heisath

A "howto setup armbian build environment" video would also be good. Just start with installed virtualbox and go over installing Ubuntu Focal, getting the github stuff, building for some board. That way new users could easier activate, test, report "missing" kernel features.

Yep the Espressobin is not optimal for routing / switching. If you need multiple eth's maybe look at the PCEngines boards (APU2) which have up to 4 dedicated Gbit ports. https://pcengines.ch/apu4d4.htm Or check the Clearfogpro / base. These atleast have a seperate SFP port, which can be used as copper/fiber with up to 2.5Gbit/s and additional LANs.

Regarding SSD performance in general: 1Gbit/s Ethernet would limit your data rates to about 120MB/s, which normal drives are also capable of doing. But an SSD also has the big advantage of faster (nearly instant) access times (to any sector/block) which is definitely noticable when running VMs (as their data is more random access than serial). Bonding several eth links together is no problem (regardless wether they are directly attached or via USB3 / whatever). See the Linux Bonding package for more info https://help.ubuntu.com/community/UbuntuBonding (for example). If have tried this on a board similar to helios4 and it works. But keep in mind, the other side of your dual network cables also has to be able to detect and bond the links.

Will need to try this. And talk with @gprovost about it, regarding their time for helios4. Lets discuss this in its own thread, as this is not coupled with 20.08 release. @Hijax and I are still testing / discussing this. Current plan is to order a few board (4) (assembled) from JLCPCB just for us to test.

I missed the meeting, sorry. Nothing to add from mvebu side though. I've been busy with the armbian-testing boards.

Well thanks for the (late) reply. I fixed this in between, somehow my apt got detached and did not update the rootfs package.