clostro

  • Content Count

    14
  • Joined

About clostro

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. - I don't see the point of baking a m.2 or any future nvme PCI-e port on the board honestly. Instead I would love to see a PCI-e slot or two exposed. That way end user can pick what expansion is needed. It can be an nvme adapter, can be 10gbe network, or SATA or USB or even a SAS controller for additional external enclosures. It will probably be more expensive for the end user but will open up a larger market for the device. We already have 2 lanes/10gbps worth of PCIe not utilized as is (correct me on this). - Absolutely more/user upgradeable and ECC ram support. - Better trays, you
  2. Just had the same thing happen to my unit. It was the first time I haven't manually rebooted the system for some reason for about 10 days I think.
  3. @allen--smithee I can see how these options could be useful to others, but in my case, all I needed was the original config. 4 HDD raid5 + 1 SSD writeback cache I would have been forced to get a QNAP if I needed more. But I'll play I would pick none, here is my counter offer- A- Replace the m.2 slot with a PMP enabled eSATA port on the back for a low end disk tower to be attached for bulk/slow storage. There are generic 8 slot (no PMP over 5, those are raid towers but still eSATA connected) towers available right now. Added bonus is more space on PCB for something.
  4. Couldn't find anything in the Helios64 patch or other RK3399 that relates to port multiplication. Not sure I'm looking at this correctly but when I search the repo for 'pmp' I'm seeing a lot of results in config/kernel folder with CONFIG_SATA_PMP=y Extrapolating those search results, I think I can assume that port multiplication is off by default in Armbian, and needs to be enabled for that specific SoC or device. No? But later I found this on https://wiki.kobol.io/helios64/sata/ So apparently port multipliers should be supported on Helios64, or will be
  5. https://man7.org/linux/man-pages/man7/lvmcache.7.html https://linuxhint.com/configuring-zfs-cache/ Here you go... use 4 HDDs and an SSD cache. Or sell your unit, quite a lot of people wanted to buy one and couldn't in time. OR, Frankenstein your unit and add in port multipliers to original SATA ports. Can add up to 20 HDDs to the 4 original SATA ports, and up to 5 SSDs to the remaining 1 original SATA port. The hardware controller specs say that it supports port multipliers, not sure about Armbian kernel, might have to modify. Btw, you can take a look at the new
  6. @gprovost Hi, my Helios64 is connected to a Zyxel XGS1010-12 switch on its 2.5gbps ports via a CAT5E 26AWG metal jacket cable. On the pc side I have the sabrent 2.5g usb network adapter, again connected to the other 2.5gbps port. I think sabrent usb adapter has the same controller as the Helios64.
  7. Yeah, I'm back to the 1gbps port too... Pushed over 3 TB of data on to the device from multiple sources simultaneously the other day and haven't had a single error. With the previous stable builds it used to throw errors quite often during transfers, so when I didn't see any errors with the new one I figured the problem must have been fixed. Today I'm loosing eth1 completely even without exerting much of a load. Maybe its because I'm pulling data from the device today instead of pushing. They are tx errors after all and not rx.
  8. I guess your tx offload is off as well since it is set that way by default but could you try again with 'ethtool -K eth1 tx off'? Asking just in case. Got the tx resets and hang ups again when I switched it back on and initiated a large transfer to see what happens with the new build.
  9. Well I did a fresh install of Armbian_20.11.6_Helios64_buster_current_5.9.14.img (didn't try to update) and hammered the disks and 2.5g network for about a day now and no tx resets or timeouts happened at all. No disconnects or hang ups.
  10. user@helios64:~$ uname -a Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux Well it isn't the cable... tried over the network disk benchmark again with a new cable (the supplied short black network cable, no metal jacket), and temporarily lost eth1 during the test again. Excuse my ignorance for I'm not an expert at any rate but could this behavior be due to any overheating of RTL8156 or VL815 chips? Could be that the thermal paste/pad isn't making enough contact on some units, which would be a very easy fix. It only starts happening u
  11. usb 4-1.4: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd r8152 4-1.4:1.0 eth1: Tx status -2 r8152 4-1.4:1.0 eth1: Tx timeout I am getting a lot of these in the logs. Sometimes 5 or 6 times in a row. Entire network activity pauses for a few seconds when I get one of these. Could it be because of a bad cable or something? Helios64 is connected to a Zyxel XGS1010-12 switch on its 2.5gbps ports via a CAT5E 26AWG cable. Cable has metal jacket jacks and everything. I read somewhere that this could be caused by a cable, but this cable was working ok before.
  12. I think so, I did a fresh install on the sd card from this file - Armbian_20.11.4_Helios64_buster_current_5.9.14.img.xz Here is the dmesg output from after reboot. Can't access the previous boot records though. This one shows a lot of eth1 errors and warnings, but it hasn't crashed yet. I tried to put the output in both spoiler and code. Hope it works.
  13. I did a fresh install of Armbian_20.11.4_Helios64_buster_current_5.9.14.img on the sd card and still having the same eth1 missing problem. Any ideas? It was working ok for the most part, but when I did a couple of crystaldisk benchmarks back to back on the helios64 share, everything went blank. Connected the usb cable, did ifconfig, and eth1 went missing.
  14. Yeah, that happens once in a while. No idea why. I'm on Armbian_21.02.0-trunk.8_Helios64_buster_current_5.9.12.img Tried usbreset and device unbind tricks but none of them worked. Maybe I didn't do it right, I don't know. So I wrote a script to reboot when it happens. Just make sure your raid and cache and whatnot gets gracefully suspended before a reboot. This problem may occur at any time. #!/bin/bash DEVICEFILE="/sys/devices/platform/usb@fe900000/fe900000.usb/xhci-hcd.0.auto/usb4/4-1/4-1.4/4-1.4:1.0" MISSINGTOKEN="/home/user/eth1_missing" if test -f "$MISSINGTOKEN"; then