Zageron

@yay thank you for additional testing. We will take note at the MTU value.

According to your latest blog post:
That's awesome to hear, thank you very much for addressing this issue! Is there any way to test this change upfront? I'd be eager to give this a spin with a self-built kernel/image if necessary, but couldn't find anything concrete in the public git repositories so far.

Nvm, I found PR 2567. With those changes applied, I can cheerfully report 2.35Gbps net TCP throughput via iperf3 in either direction with an MTU of 1500 and tx offloading enabled. Again, thanks so much!
 
One way remains to reproducibly kill the H64's eth1: set the MTU to 9124 on both ends and run iperf in both directions - each with their own server and the other acting as the client. But as the throughput difference is negligible (2.35Gbps vs 2.39Gbps, both really close to the 2.5Gbps maximum), I can safely exclude that use case for myself. I can't recall whether that even worked on kernel 4.4 or whether I even tested it back then.
 
For whatever it's worth, here's the 5.9 log output from when said crash happens:
Jan 21 22:51:55 helios64 kernel: r8152 4-1.4:1.0 eth1: Tx status -2 Jan 21 22:51:55 helios64 kernel: r8152 4-1.4:1.0 eth1: Tx status -2 Jan 21 22:51:55 helios64 kernel: r8152 4-1.4:1.0 eth1: Tx status -2 Jan 21 22:51:55 helios64 kernel: r8152 4-1.4:1.0 eth1: Tx status -2  

We are working on this issue.
The same Realtek driver working fine on an Ubuntu laptop (amd64), Helios4 (armhf), and Helios64 LK 4.4.
We are looking into USB host controller driver, it seems there are some quirks not implemented on mainline kernel.

Rare mistake by Igor!
 
In few years I been lurking here, this is only time I can recall such thing happening.  Of course everyone make mistakes, and there were probably some I was not aware of, but this is first time I can remember such thing happening.

Likewise after upgradign to Armbian20.113 Buster eth1 2.5gb network disappeared.

sudo apt-get update && sudo apt-get dist-upgrade -y  
This will upgrade your unit. I rebooted after doing this, but I'm not sure that you need to.

arf, thank you,
this will teach me to read wikis too quickly ..., or not ...

uname -a
Before dist-upgrade: 5.8.17-rockchip64 #20.08.21 SMP PREEMPT Sat Oct 31
After dist-upgrade & reboot: 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27

@Zageron run
echo ledtrig-netdev | sudo tee -a /etc/modules add the modules into auto load list.
 
apparently /etc/modules is not modified during upgrade.

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

To activate the network activity led load kernel module ledtrig-netdev and restart helios64-heartbeat-led.service.
 
 

Thanks for the quick response, @aprayoga!
 
I gave it a shot and unfortunately it doesn't seem to work for me.
 
I've upgraded to Armbian 20.11, which includes LK 5.9:
 
XXXXX@helios64:~ $ uname -r 5.9.10-rockchip64 XXXXX@helios64:~ $ cat /etc/os-release PRETTY_NAME="Armbian 20.11 Buster" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"  
I've created that file and applied the user overlay as suggested:
 
XXXXX@helios64:/etc $ cat dwc3-0-device.dts /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&usbdrd_dwc3_0>; __overlay__ { dr_mode = "peripheral"; }; }; };  
XXXXX@helios64:/etc $ sudo armbian-add-overlay dwc3-0-device.dts Compiling the overlay Copying the compiled overlay file to /boot/overlay-user/ Overlay dwc3-0-device was already added to /boot/armbianEnv.txt, skipping Reboot is required to apply the changes XXXXX@helios64:/etc $ sudo reboot  
And then after the reboot:
 
XXXXX@helios64:~ $ sudo modprobe g_mass_storage file=/dev/sda,/dev/sdb,/dev/sdd iSerialNumber=1234567890 iManufacturer="Kobol Innovations" iProduct=Helios64  
I see the following in /var/log/syslog:
 
Nov 27 15:26:36 localhost kernel: [ 3714.194647] Mass Storage Function, version: 2009/09/11 Nov 27 15:26:36 localhost kernel: [ 3714.194664] LUN: removable file: (no medium) Nov 27 15:26:36 localhost kernel: [ 3714.194866] LUN: file: /dev/sda Nov 27 15:26:36 localhost kernel: [ 3714.194973] LUN: file: /dev/sdb Nov 27 15:26:36 localhost kernel: [ 3714.195075] LUN: file: /dev/sdd Nov 27 15:26:36 localhost kernel: [ 3714.195083] Number of LUNs=3 Nov 27 15:26:36 localhost kernel: [ 3714.195344] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 Nov 27 15:26:36 localhost kernel: [ 3714.195354] g_mass_storage gadget: g_mass_storage ready  
I've tried with both a Windows PC and a Linux (Debian) PC, with no luck.
 
I can try and provide anything else needed to troubleshoot, though it may take some time as I'm limited to just one post per day.
 
Thanks!

Hi again,
 
Yes, the lights were solid blue after boot (power and hdds, nothing else), so the comment about not getting a clean boot make sense.
 
I was monitoring the router but no ip was coming up for it, so this again makes sense as it wasn’t really booting with the sd card.
 
Here’s what actually worked last evening (don’t remember the exact order):
-          Changed the sd card image from Armbian_20.08.13_Helios4_buster_current_5.8.16.img to Armbian_20.11_Helios64_buster_current_5.9.10.img (yes, using Etcher), initially I was using the older image for what seemed to be stability reasons…
-          Before burning the image again - reformatted the card from exFAT to FAT in Windows 10 (as mentioned, not really much experience with Linux so this might have been the cause)
-          Moved the device from the left side of my desk to the right
 
It powered up and connected via usb - COM6 with my desktop as I was checking anyway every time before trying (for example desktop was always COM6, laptop always COM3).
 
Looks fine now, power light on, system light blinking, no hdd lights (as I don’t have any yet).
 
Even installed OMV which took about 20 mins, but I am able to access it.
 
Now off to buying disks, fun times ahead
Thanks for your time, people!

Ok interesting.
 
On my side I don't see any iperf difference increasing MTU beside seeing more retries.
 
Here my perf with default MTU 1500.
 
Helios64 Transmitting (TX checksum offload disabled)
----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.10.254, port 59252 [ 5] local 10.10.10.2 port 5201 connected to 10.10.10.254 port 59254 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.01 sec 177 MBytes 1.48 Gbits/sec 0 4.29 MBytes [ 5] 1.01-2.01 sec 224 MBytes 1.88 Gbits/sec 0 4.29 MBytes [ 5] 2.01-3.01 sec 224 MBytes 1.88 Gbits/sec 0 4.29 MBytes [ 5] 3.01-4.01 sec 221 MBytes 1.85 Gbits/sec 0 4.29 MBytes [ 5] 4.01-5.01 sec 220 MBytes 1.85 Gbits/sec 0 4.29 MBytes [ 5] 5.01-6.01 sec 218 MBytes 1.82 Gbits/sec 0 4.29 MBytes [ 5] 6.01-7.01 sec 201 MBytes 1.69 Gbits/sec 0 4.29 MBytes [ 5] 7.01-8.01 sec 222 MBytes 1.87 Gbits/sec 0 4.29 MBytes [ 5] 8.01-9.01 sec 216 MBytes 1.81 Gbits/sec 0 4.29 MBytes [ 5] 9.01-10.00 sec 220 MBytes 1.86 Gbits/sec 0 4.29 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.09 GBytes 1.80 Gbits/sec 0 sender  
Helios64 Receiving
----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.10.254, port 59256 [ 5] local 10.10.10.2 port 5201 connected to 10.10.10.254 port 59258 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 261 MBytes 2.19 Gbits/sec [ 5] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 2.00-3.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 5.00-6.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 6.00-7.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 7.00-8.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 8.00-9.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 10.00-10.00 sec 601 KBytes 2.37 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 2.72 GBytes 2.34 Gbits/sec receiver  
Just for the sake of clarification because iperf can be confusing. By default iperf client test upload speed.
 
iperf -c <helios64-ip>  = test RX speed of Helios64
 
iperd -c <helios64-ip> -R = test TX speed of Helios64
 

Hi,
 
I wanted to convert my root filesystem to btrfs.  This allows me to use snapper to take regular snapshops.  I also use btrbk to send my snapshots to my secondary storage (also a btrfs array).  My root filesystems is installed to eMMC, but there isn't any reason you couldn't do this with an sd card.  These instructions are done with a laptop running Linux.  I'm using Debian in this case, although any distro with a recent kernel and btrfs tools installed should work.
 
CAVEATS:
The current u-boot image (2020.08.21) doesn't support booting natively to btrfs.  u-boot *does* support btrfs though.  Hopefully a future build of u-boot will add btrfs support.  To work around this, we have to create an ext4 /boot partition, and then a btrfs root partition.
 
1. To start, I booted the helios64 via sd card to the USB mass storage image (https://wiki.kobol.io/helios64/install/emmc/).  I then connected a laptop to the helios64 via the USB-C cable, and the emmc appeared as /dev/sdb.  The rest of these instructions will assume the eMMC is /dev/sdb, so please adjust accordingly for your system.
 
2. Mount the eMMC root filesystem on the host:
# mkdir /mnt/nasrootext4 # mount /dev/sdb1 -o ro /mnt/nasrootext4  
3. Back up the contents of the root filesystem:
# tar -C /mnt/nasrootext4 --acls --xattrs -cf root_backup.tar .  
4. Make a backup of the partition layout (in case you decide to revert this modification):
# fdisk -l /dev/sdb | tee nas_fdisk.txt  
5. Unmount the filesystem, and run fdisk on it.  Make note of the start sector.  It should be 32768.
# umount /dev/sdb1 # fdisk /dev/sdb Command (m for help): p Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 30230303 30197536 14.4G 83 Linux  
6. Delete the existing partition ('d')
7. Create a new partition ('n')
8. Select 'primary' partition type
9. Select partition number 1
10. Select first sector: 32768 (This is very important to get right, and should match the start sector of the partition that was just deleted)
11. Select last sector: +512M (this create a 512MB /boot partition)
12. You will see a message "Partition #1 contains a ext4 signature.".  This is okay.  I selected 'n' (don't remove signature) but it doesn't matter.  You should probably remove the signature since we're going to create a new ext4 filesystem anyway.
13. Create new partition ('n')
14. Select 'primary' partition type
15. Select partition number 2
16. First sector: 1081344 (this is one more than the end sector of the other partition)
17. Last sector: (leave the default as the full drive, 30535679 in my case)
18. Print the layout to confirm:
Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 1081343 1048576 512M 83 Linux /dev/sdb2 1081344 30535679 29454336 14G 83 Linux  
19. Write the partition table to disk and exit ('w')
20. Create a new ext4 filesystem on the first partition: 'mkfs.ext4 /dev/sdb1' (you may need to add -F if it complains about an existing ext4 signature)
21. Create a new btrfs filesystem on the second partition: 'mkfs.btrfs /dev/sdb2'
22. Mount the new root filesystem:
# mkdir /mnt/nasrootbtrfs # sudo mount -o compress=zstd /dev/sdb2 /mnt/nasrootbtrfs  
23. Make some initial subvolumes (note that '@' will be the root subvolume, as this is preferred by 'snapper'):
# cd /mnt/nasrootbtrfs # btrfs subvol create @ # btrfs subvol create @home # btrfs subvol create @var_log  
24. Mount the boot partition, and the @home and @var_log subvolumes
# cd @ # mkdir boot # mount /dev/sdb1 boot/ # mkdir home # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@home home # mkdir -p var/log # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@var_log var/log # mount | grep sdb /dev/sdb2 on /mnt/nasrootbtrfs type btrfs (rw,relatime,compress=zstd,space_cache,subvolid=5,subvol=/) /dev/sdb1 on /mnt/nasrootbtrfs/@/boot type ext4 (rw,relatime) /dev/sdb2 on /mnt/nasrootbtrfs/@/home type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=258,subvol=/@home) /dev/sdb2 on /mnt/nasrootbtrfs/@/var/log type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=260,subvol=/@var_log)  
25. Note that our current directory is '/mnt/nasrootbtrfs/@'
26. Untar the old root filesystem into the new root directory.  Since boot, home, and var/log are mounted, tar will extract the relevant data into these mounted filesystems.
# tar -xvf /root/helios64_root.tar --acls --xattrs --numeric-owner |@ tee /root/extract_log.txt This is the only spot where things did not go as expected.  I received a handful of errors about "No space left on device" while untarring.  These seem to be transient btrfs errors. I use btrfs pretty extensively at work, and I've seen cases in the past on older kernels where btrfs would falsely report ENOSPC when the filesystem was under heavy load.  I'm not sure if that is what is happening here, but I would guess it's a bug.  It could be a bug in the kernel on my laptop, or it could be a bug in the usb-c mass storage export on the helios64.  To recover from this, I ran the tar command a couple of times.  I continued to receive these errors on different files.  I did this three or four times.  I also tried removing --acls and --xattrs, but it didn't seem to make much of a difference.  On my last attempt to untar, all of the files that failed happened to be from usr/lib/python3, so I untarred just that directory: 'tar -xvf /root/helios64_root.tar --numeric-owner ./usr/lib/python3'.  That extracted without error.  I was satisfied that everything made it back on disk.  Perhaps if you only extracted one top-level directory at a time, it would not produce any errors.  Maybe there is some way to slow down the 'tar' to avoid these ENOSPC errors.
 
27. After extracting the root filesystem, I made a snapshot of it: 'btrfs subvol snap -r . root_post_copy'
28. Update /mnt/nasrootbtrfs/@/etc/fstab.  This was my old fstab:
Old version: UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
Look up the new UUID for /dev/sdb2.  I did this by running 'ls -l /dev/disk/by-uuid').  Updated /etc/fstab:
UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f / btrfs defaults,noatime,compress=zstd,ssd,subvol=@ 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /home btrfs defaults,noatime,compress=zstd,ssd,subvol=@home 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /var/log/ btrfs defaults,noatime,compress=zstd,ssd,subvol=@var_log 0 0 UUID=fd5b620c-57e2-4031-b56c-3c64ce7c7d5f /boot ext4 defaults,noatime 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
29. Modify /mnt/nasrootbtrfs/@/boot/armbianEnv.txt.  In particular modify rootdev, rootfstype, and add 'extraargs'.  Old version:
verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
New version:
verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f rootfstype=btrfs usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u extraargs=rootflags=subvol=@  
30. Make a 'boot' symlink.  I'm not sure if this is necessary, but u-boot expects the boot files to be in the '/boot' directory on the root filesystem, but they are now in the root directory of the boot partition.  This symlink makes sure that if u-boot tries to access /boot/foo, it will actually access /foo.
# cd /mnt/nasrootbtrfs/@/boot # ln -s . boot  
31.  Unmount everything:
# umount /mnt/nasrootbtrfs/@/var/log # umount /mnt/nasrootbtrfs/@/home # umount /mnt/nasrootbtrfs/@/boot # umount /mnt/nasrootbtrfs/  
32. Power off helios64
33. Remove sd card
34. Start picocom on your laptop ('picocom -b 1500000 /dev/ttyUSB0')
35. Turn on helios 64 and look for startup.
 
TROUBLESHOOTING:
Of course this did not work on the first attempt for me.  After rebooting the helios64, it never successfully booted into Linux.  I didn't see any errors from u-boot.  To troubleshoot, I wrote the original helios64 debian buster image to sd card and booted the helios64 to that.  I mounted /dev/mmcblk1p1 to /mnt, and changed the 'verbosity' to 7 in armbianEnv.txt.  I eventually discovered that I had the UUID wrong in /boot/armbianEnv.txt.  Correcting that value fixed the issue, and the helios64 booted successfully from eMMC.
 
SETTING UP AUTOMATED SNAPSHOTS AND BACKUPS:
Enabling 'snapper' for automated root snapshots was very easy:
1. sudo apt install snapper
2. sudo snapper -c root create-config /
 
The debian snapper automatically take snapshots before and after apt upgrades.  However since /boot is a separate filesystem, this is not included in these snapshots.  As a workaround, I added an apt hook which rsyncs /boot to /.bootbackup before the snapshots are made.  Note that the 'snapper' hook is /etc/apt/apt.conf.d/80snapper, so I created /etc/apt/apt.conf.d/79-snapper-boot-backup:
# /etc/apt/apt.conf.d/79-snapper-boot-backup DPkg::Pre-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; }; DPkg::Post-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; };  
This takes care of automated snapshots.  I still want snapshots stored on another drive (or another system) for redundancy.  I'm using 'btrbk' to do this.  btrbk wants the btrfs top-level subvolume mounted somewhere.  To do so, I created the directory /mnt/btr_pool, and added the following line to /etc/fstab:
UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /mnt/btr_pool/ btrfs defaults,noatime,compress=zstd,ssd,subvolid=5 0 0  
My spinning drive array on the helios64 is a btrfs filesystem, and I have it mounted on /srv/dev-disk-by-label-helios64_btrfs_raid1.  I created a '/srv/.../backups/helios64/btrfs/volumes' directory.  I then created the following three files:
 
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/btrbk.conf:
timestamp_format long volume /mnt/btr_pool snapshot_dir btrbk snapshot_preserve 30d snapshot_preserve_min latest target_preserve 7d 8w 6m target_preserve_min latest target send-receive /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/volumes subvolume @ subvolume @home subvolume @var_log  
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/rsync_boot.sh:
#!/bin/sh set -e -x mountpoint /boot [ -e /.bootbackup ] rsync -a --delete /boot /.bootbackup  
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/run.sh
#!/bin/bash set -e -x CDIR=$( dirname ${BASH_SOURCE[0]} ) ${CDIR}/rsync_boot.sh btrbk -c ${CDIR}/btrbk.conf run  
I then added a daily cron job which runs the 'run.sh' script.
 
Well, that was a longer post than I had imagined.  I hope someone finds it helpful.

Hi folks,
 
I got my helios64, assembled it during the weekend and can’t seem to actually install it.
 
Here are some of the things I tried (I'm on windows 10 btw, I don’t have hdd drives yet, I assume this would not be an issue):
·         2 sd cards (one of which is a Samsung as recommended in the wiki), two computers (with correct com ports as visible in the device manager, driver is installed), tried both on usb2 and usb3
·         USB cable has been trimmed to fit the case properly - also tried with the back panel off and directly connected to the board
·         the devices starts up as soon as I plug in the power cord - I then use the power button to shut if off, then open the console and start it up (I did use the 4 seconds to shut it off and make sure the leds are not on)
·         (when I plug it in, the system light turns on red for just a millisecond, and then off, and all other light blue)
 
After start-up:
-          No light on the system led, not even blinking.
-          Power and hdd leds are all blue (constant on).
 
Anything I should be trying next? Thanks for reading.
 
PS. Not really much an expert on linux, last time I used it was years ago when I was tweaking my prior nas.

Yay 24 hour delay is over. This is regarding the degraded performance of the 2.5gbe on 5.8. I am unsure if my iperf results are aligning with what others are seeing. Given that tx offload is definitely off, I assume so.
 
Formulated context and question:
I have just put my helios64 together. I am seeing degraded performance of the 2.5gbe interface as warned.
The notes I saw everywhere were "disable tx checksum offload".
How do I check if tx offloading is on or off?
 

I tested with ethtool, and yes it is off.
❯ sudo ethtool -k eth1 | grep tx-checksum tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed]  
I assume I have nothing else to do but wait for patches to improve the degraded performance at this point?
 
Thanks for your patience and your answers!

@Zageron Yeah please formulate a clear question.
 
To check if tx offloading is on or off
 
ethtool -k eth1 | grep tx-checksum  
Currently TX checksum offload for all network interfaces on rockchip64 family is disable in Armbian by default.

Yay 24 hour delay is over. This is regarding the degraded performance of the 2.5gbe on 5.8. I am unsure if my iperf results are aligning with what others are seeing. Given that tx offload is definitely off, I assume so.
 
Formulated context and question:
I have just put my helios64 together. I am seeing degraded performance of the 2.5gbe interface as warned.
The notes I saw everywhere were "disable tx checksum offload".
How do I check if tx offloading is on or off?
 

I tested with ethtool, and yes it is off.
❯ sudo ethtool -k eth1 | grep tx-checksum tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed]  
I assume I have nothing else to do but wait for patches to improve the degraded performance at this point?
 
Thanks for your patience and your answers!