Salamandar

As i said in the original post, I tried 2 hard drives, the first one being rated for 700mA.

On the link @Igor sent, the spike is almost 2s long. My power meter has a 0.1s resolution so I don't know why it couldn't catch it… anyways I could plug my oscilloscope on the power meter to have a better resolution.

That's not a Linux issue here, but a hardware issue. The hard drives run fine with armbian on a rpi3b+

I just received my USB power meter AND an usb splitter. * With the usb splitter + an external power supply, the 1A hdd WORKS FINE ! This is REALLY a usb power issue. * The power meter tells me the HDD draws 400mA idle. So... I don't even have the advertised 900mA. @kobol guys, any help on that ?

I've been trying to connect a USB hdd for a while now, and depending on the SATA disk and the USB<->Sata adapter I've had different behaviours : * 700mA hdd * Adapter A works, can mount and copy * Adapter B is detected, the SATA device too in dmesg, but does not appear in lsblk. * 1A hdd (Seagate Barracuda 2To 2.5'') * Adapter A seems to be detected, the disk tries to start (sde is showing in dmesg) but usb device disappears, reappears etc ("usb disk bootloop") * Adapter B is not even detected in dmesg or lsusb ! Obviously, the 4 configurations perfectly work on a x86 host. What could be going on ? I'm pretty confident this is a USB current limitation. I'm buying a USB-A + USB-A -> USB-C cable to power the disk from an external source too, will see if that helps. If that's the case, this current limitation is HIGHLY PROBLEMATIC, please fix it in a future revision of the board

I added voting options, please revote ! EDIT: crap… We can't edit our votes, I did not expect that

Weird, that's not something I decided when setting up the post. Well I'll just add "support announced features" Also the 2.5GB connector is already fixed in batch 2. I have a zraid (4 HDD), never had an issue. You may need to contact Kobol on this. True, I didn't think of that. Thanks.

(Some explanations to my votes : ) * I printed handles that directly screw with the fan screws on the back side. That's way easier to transport this way ! * The CPU is great, but 4GB of Ram is not enough for some purposes. * The shared SATA between sata1 and the m2 port ain't great. Would an NVMe port be possible ? * A standard PCB dimensions would not be difficult to do (only screw positions have to change) and would make a precedent for other SBC. * I've had low current issues on the USB-A ports for some usb hdds.

Hi everyone ! I'm really happy with my Helios64, running fine with no major issues. BUT This product can obviously be improved with future revisions, while keeping the same base. The Kobol guys told me to open a thread here to discuss what would be great improvement or new features. I'm starting with things off my mind, but please ask me to add things to this list. An explanation would be great in the comments.

Yeah, I tried a manual upgrade but /boot was too small, and it wouldn't reboot after a resize2fs. So I reinstalled my server, and eth1 is running without any issue ! Looks like it really was a legacy kernel issue.

It sometimes disconnects while idle (my Home Assistant web gui does not update, and I discover hours later it had been disconnected), sometimes while transferring data. OK, then I guess I will switch to `current`. Is there any easy switching procedure or should I just install `linux-current-image` ?

I ran the 5.8/5.9 kernel for weeks without any issues (no RAM unstability, no crash, no ethernet issue). Now I reinstalled the thing and came back to a 4.4 kernel to have USB-C support. The thing is… Once every hours, the 1GBps Ethernet disconnects. Once connected through serial port, I can check the port status and it's shown as `Unknown`. I can `ip link set down eth0; ip link set up eth0` to set it back up. Am I the only one with this issue ? Is it well known on 4.4 and solved on 5.9 ?

What do you mean by "in the tree" ? Do you mean in /usr/src/zfs where the zfs-dkms module installs the sources ? Right now the build is done inside the source directory of ZFS, and I'm looking into building it out-of-source (I'm gonna read the dkms scripts, I think they build out-of-source).

@ShadowDance Crap, I didn't even see those headers were available ! I already implemented the modification of the headers version ! Let's roll back. Thanks, feel free to open issues if needed.

Hi, I'm still unable to build the module correctly. The ZFS kernel module is build for kernel '4.4.213-rockchip64' (the headers version name) but the kernel is '4.4.213-rk3399'. spl: version magic '4.4.213-rockchip64 SMP mod_unload aarch64' should be '4.4.213-rk3399 SMP mod_unload aarch64' I'm not sure this can be fixed without editing kernel headers, either : /usr/src/linux-headers-4.4.213-rockchip64/include/config/kernel.release /usr/src/linux-headers-4.4.213-rockchip64/include/generated/utsrelease.h @ShadowDance Are you using the "current" 5.9 kernel ? Maybe this has been fixed for this kernel ? BTW as the procedure is a bit tiring to do by hand, I wrote some scripts to automate this (build module on Ubuntu, utils on Buster) : https://github.com/Salamandar/armbian_zfs_compiler/ MOD EDIT: Above is third party script, as always, make sure you understand what is going on before running it on your system. Having gotten that disclaimer out of the way, thanks for your contribution, @Salamandar! I took the liberty of marking this as solution. I also made note of the link to refer others to, later. Cheers, TRS-80