Zageron

  • Content Count

    18
  • Joined

  • Last visited

Everything posted by Zageron

  1. If these two things were added I would definitely get another one would be: - a transceiver / SFP+ port with onboard wiring supporting 10gbe and/or 25gbe. (10gbe ports are too big / expensive / hot for them to work cheaply on a board like this.) - A dedicated lane for the m2 SSD, or replace it with a dedicated 4x nvme slot. The machine works just fine as is otherwise, especially with the new 2.5gbe fixes. (It bodes well for the remainder of the unfixed issued. :)) (Having two would mean I could mirror the enclosure to an offsite location, though that's be pric
  2. Alrighty, thank you. I've been meaning to learn Ansible, so I'll give that a shot.
  3. My plan is as follows: - Insert SD card. - Make a clone / back-up of boot and system using armbian-config whenever I'm about to do something major. (boot and system are both on eMMC) - "unclick" SD card and leave it in the back. - (repeat, until something breaks, and then just insert it and restore using armbian-config if something goes wrong.) I am confused by the eMMC to SD card path though. Here's some context: ❯ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 86.6M 1 loop /snap/core/10578 loop1 7:1
  4. fwiw I've stopped using the 2.5gbe interface until this disconnection issue is resolved.
  5. After upgrade to Armbian 20.11.3 Buster with Linux 5.9.14-rockchip64 eth1 has vanished. ❯ sudo ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 64:62:66:d0:06:18 brd ff:ff:ff:ff:ff:ff Any ideas? http://ix.io/2I2U
  6. 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.
  7. sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service
  8. ❯ sudo systemctl status helios64-heartbeat-led.service ● helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64 Loaded: loaded (/etc/systemd/system/helios64-heartbeat-led.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2020-11-28 23:19:56 PST; 13min ago Process: 1158 ExecStart=/usr/bin/bash -c echo heartbeat | tee /sys/class/leds/helios64\:\:status/trigger (code=exited, status=0/SUCCESS) Process: 1177 ExecStart=/usr/bin/bash -c echo netdev | tee /sys/class/leds/helios64\:blue\:net/trigger (code=exited, status=1/
  9. JohnnyMnemonic you can either wait 24 hours now that you have a like, or you can join the irc channel and ask to be activated.
  10. http://ix.io/2FHd This is the machine in the broken state. (Requiring reboot)
  11. I see! Yes, modifying settings on the windows machine has improved both. However, I am still seeing consistent lock-up / crashing of the interface. Is there anything I can grab for you for details? PS L:\> iperf3.exe -c helios64.local -R -t 700 Connecting to host helios64.local, port 5201 Reverse mode, remote host helios64.local is sending [ 4] local 192.167.0.1 port 4362 connected to 192.167.0.2 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 205 MBytes 1.72 Gbits/sec [ 4] 1.00-2.00 sec 234 MBytes 1.96 Gbits/sec [ 4] 2.00-3.00
  12. Default Offload Settings with 9000 MTU: PS L:\> iperf3.exe -c helios64.local Connecting to host helios64.local, port 5201 [ 4] local 192.167.0.1 port 59373 connected to 192.167.0.2 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 237 MBytes 1.98 Gbits/sec [ 4] 1.00-2.00 sec 255 MBytes 2.14 Gbits/sec [ 4] 2.00-3.00 sec 248 MBytes 2.08 Gbits/sec [ 4] 3.00-4.00 sec 241 MBytes 2.02 Gbits/sec [ 4] 4.00-5.00 sec 250 MBytes 2.10 Gbits/sec [ 4] 5.00-6.00 sec 244 MBytes 2.05 Gbits/sec [ 4] 6.00-7.00 sec 241 MByte
  13. Have you tried checking your router's dhcp for a lease on the helios64? If you have the ethernet plugged in when starting it up, and it makes it through sdcard boot, regardless of your serial console it should get a lease. (Then you can SSH in with the same credentials.) I also had no console output when I first tried to set it up, and ended up using the router to discover what the IP was. Make sure you are using the correct COM address. I had to install the driver, and I was on COM4.
  14. The other end looks like this: PS C:\Users\Zageron\Exercism\rust\proverb> NetAdapterChecksumOffload Name IpIPv4Enabled TcpIPv4Enabled TcpIPv6Enabled UdpIPv4Enabled UdpIPv6Enabled vEthernet (WSL) RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled Helios Direct Disabled Disabled Disabled Disabled Disabled LAN WAN RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled vEthernet (Default Switch) RxTxEnabled RxTxEnabled R
  15. 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
  16. ❯ sudo iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.167.0.1, port 23497 [ 5] local 192.167.0.2 port 5201 connected to 192.167.0.1 port 23498 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 163 MBytes 1.37 Gbits/sec [ 5] 1.00-2.00 sec 149 MBytes 1.25 Gbits/sec [ 5] 2.00-3.00 sec 104 MBytes 868 Mbits/sec [ 5] 3.00-4.00 sec 141 MBytes 1.19 Gbits/sec [ 5] 4.00-5.00 sec 174 MBytes 1.46 Gbits/sec [ 5]