tkaiser

What a 'valuable' suggestion for physical problems happening on the link layer. Good luck to all blaming software when dealing with hardware issues. @Gord_W: A link is something that is established between two ends. What about the other end? Obviously the problem does not live inside your SBC if you already exchanged them and the problem persists with identical symptoms (hint: look at the other end of the link and what connects both ends: switch/hub port, Auto negotiation/MDI-X settings there, Ethernet cable)

23% 'one star rating' at least for me is a very clear 'never ever buy such crap' indicator. 2nd 1 star review names the problem already: As very often with cheap PSUs you can not trust in what's printed on them. 5V/4A would mean 20W if you multiply both numbers. But crappy PSUs either provide 5V (no load) or 4A but not both at the same time (voltage drop under load). And the same phenomenon can be observed with cables between PSU and board if wires are too tiny. Incoming voltage at the board dropping due to cable/contact resistance too high. And this happens only with some load generated (Ohm's law). Can a moderator now please move this whole thread to the subforum where it belongs too? Thanks!

Channels 12 and 13 are only allowed in some countries. You need to adopt to this situation: https://forum.armbian.com/topic/3676-raspberry-pi-zero-wireless-rumors-speculation/?do=findComment&comment=27144 (workaround not a solution)

For 2 HC1 in a pure NAS scenario 6A are sufficient (keep this in mind when you measure consumption at the wall since your oversized PSU is highly inefficient in this low load range and wastes a lot of energy). I write it again one last time: the problem is called underVOLTAGE (and not amperage too low). Meanwell PSUs have adjustable voltage so you need to ensure that your PSU is providing 5.2V and not 4.7V since otherwise you most probably run into the same issues again. Edit: According to the LRS-150F-5 datasheet voltage is adjustable between 4.5V and 5.5V so without a multimeter it's not possible to make any reasonable use of this power supply (since if it's set to much lower than 5V undervoltage at the disk/controller might happen again)

There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see here how to do so). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069

There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see above). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069

This is known but currently we implemented this only in a somewhat hackish attempt for Pine64/Pinebook (and obviously no one so far took care of OPi Prime): https://github.com/armbian/build/blob/91ce8682cf672c44061fbf03b611b9fcf1226624/config/sources/sun50iw1.conf#L66 No idea though how to solve this in a more generic way (or without additional hacks)

Usually a sign of either USB cable/receptacle crappiness (impossible on HC1) or undervoltage. You should check how much voltage your PSUs do really provide under load (Ohm's law). More info: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=32340

Probably some more information: https://www.cnx-software.com/2017/12/14/more-low-cost-arm-linux-nas-platforms-coming-soon-popcorn-hour-transformer-xl-odroid-hc2/#comment-550021 (and comments below) BTW: I only now realized that there's no SD card slot on this board...

Well, choosing Allwinner's dog slow SD card interface is most probably not the right platform to draw any such conclusions. It would need one of the other boards that are able to negotiate higher speed modes to fully 'benchmark' such a card since the bottlenecked interface between host and card influences all numbers. Besides that thanks for the heads-up. I just checked prices and availability of these SanDisk A1 cards and this doesn't look too bad: https://geizhals.de/?fs=Sandisk+"UHS-I+A1"&in= -- when it's time to buy SD cards again I'll skip Samsung EVO this time and check the SanDisk cards instead

Set up a Wi-Fi connection as root with network manager on your other board (OPi Plus 2?). Copy the created profile below /etc/NetworkManager/system-connections/ to the image of your NEO Air. Done. If you want to support more than one location, add as many profile files as necessary. I do this all the time since 18 months now and it works always. Only thing you have to take care of: NM has to create a profile that is useable by all users (then Wi-Fi connection is established at boot). If you fail here then the Wi-Fi connection will be activated only after login which renders the whole attempt useless.

Settings matter as already explained above. I would assume after switching to performance cpufreq governor some numbers look different/better? sudo cpufreq-set -g performance

To quote the most important sentence there (emphasis by me): So how is Armbian affected? Allwinner A10 boards (Cortex-A8): easy solution, stop supporting them, it's only one board left AFAIK Micro-USB powered support nightmares called MiQi and Tinkerboard (Cortex-A17): in my personal opinion support for power hungry boards with Micro-USB for DC-IN should be phased out. Once this is done problem solved ODROID-XU4 (Cortex-A15): stop supporting legacy kernel and switch next from 4.9 to 4.14 (in the hope of an upstream fix arriving soon) That's it. BTW: it's frustrating how much attention Meltdown and Spectre get compared to more severe security issues Edit: I forgot i.MX6 (Cortex-A9). Given how 'popular' these boards are these days the most easy 'solution' would also be to phase support out.

Of course not since it absolutely makes no sense at all. Using the HC1 without connected disk is a pretty strange use case. If you for whatever reasons feel the need to use Exynos boards why not using an XU4 running off SD card and choosing a quality USB pendrive for storage? It all depends on your needs and if you need high random IO performance then a connected SSD will be for sure the best solution (or even better choosing a different device since USB3 negatively affects random IO a lot) And please open up a new thread wrt alternatives since this is a REVIEW thread that should remain somewhat readable.

Yes. And I also provided a link in the post to Hardkernel's own measurements (3.6W minimum). I measured the only realistic use case possible: HC1 with a connected but sleeping disk (sent to sleep/standby back then by a JMS578 firmware setting). So since there's always the JMS578 active (using two highspeed PHYs -- USB3 SuperSpeed at one side and SATA 3.0 at the other) and a 'sleeping' disk idle consumption must be higher than a XU4 without an external disk. As soon as you do the same there (connect a good USB-to-SATA bridge with a XU4 powered disk behind) you get also higher numbers of course. And power consumption varies by disk. I tested another time with HC2 and a SSD drew 0.4W in sleeping state while a 3.5" Barracuda needed 1.4W while not spinning. I already suggested to Hardkernel overthinking the PCB design to allow either only the JMS578 to be powered through a GPIO or even both JMS578 and disk. Hardkernel's answer (nothing more heard since then):

BTW: this forum is searchable. It's pretty easy to search for g_ether and then end up here for example:

Which image? Did you realize that Armbian currently neither supports Core nor Core2? If you use an image with eMMC support (eg. those for NEO Air) it should just work, if you use any image without eMMC support (eg. those for NanoPi NEO) it can't work.

If you look at page 1 of this thread there are thermal values from my 1st HC1. When my HC2 arrived some weeks ago I noticed a lot higher temperatures reported in the beginning. I carefully 'massaged' the PCB and this did the trick: temperatures later only a few degrees above HC1 (which is to be expected due to the additional 12V/5V DC-DC converter). So trying to get a better contact between SoC and heatsink (spreading the thermal paste) is always a good idea if the temperatures you get are a bit off. https://forum.odroid.com/viewtopic.php?t=27665

Just for the record: your above procedure is a great recipe to get a corrupted rootfs so you shouldn't be too surprised if the filesystem gets corrupted and the board fails to boot the next time. There are solutions for this problem (do a search for 'read-only rootfs' for example).

Leave everything as is and simply use this command: /usr/sbin/log2ram write ; sync & This will write changes to SD card while still lowering write amplification a lot (high 'write amplification' is the reason why SD cards and other flash media die too early)

https://github.com/armbian/build/blob/8b4d703f415de214e2de7af467a448ead7a93a18/packages/bsp/common/etc/init.d/firstrun#L126-L130 Ugly hack, not even needed with legacy kernel and breaking network on 2nd boot.

Usually we use 'ondemand' in Armbian (interactive is only useful on some sunxi legacy kernels) but apply the following tweaks: https://github.com/armbian/build/blob/751aa7194f77eabcb41b19b8d19f17f6ea23272a/packages/bsp/common/etc/init.d/armhwinfo#L82-L94 So the eMMC on this board is not that slow as on earlier board revisions (I had the opportunity to verify this recently since I let f3write/f3read run yesterday and the tool reported an average write speed of just 6.3MB/s on my BPi M2+). And what you observed is only some form of eMMC internal caching. As soon as the amount of data is small enough write speeds are high just to drop after some time. Easy to test for by combining two benchmark runs: iozone -e -I -a -s 3000M -r 16384k -i 0 ; iozone -e -I -a -s 100M -r 16384k -i 0 The 2nd iozone call will report the real write speed without any caching involved. And similar effects can be observed with small/cheap SSDs too (I've 5 small 120 / 128 GB here lying around just for testing, four show write performance of +300 MB/s but slow down to as low as low as 60 MB/s after a certain amount of data has been written, only my most recent one, a Transcend TS120GMTS420, is able to retain write performance of +500 MB/s regardless how much data will be written). And of course every write to flash media shorten its life but the FTL (flash translation layer) takes care of wear leveling to evenly spreads writes across flash cells so the most important thing to have in mind is 'write amplification'. And yes, on most flash media a performance degradation happens after total amount of data being written exceeding the storage capacity since now the FTL (controller) without TRIM has no clue which pages contain data and which not and starts to move around unused data as part of garbage collection and wear leveling (that's why quality SD cards can be considered the better choice than eMMC since with those SD cards you can use SD association's SD Formatter after some time and send an ERASE CMD38 to the device which restores factory performance -- see last 3 paragraphs here)

Quoting the documentation: DT overlays are a Work-in-Progress (WIP) feature, present only in fresh images starting with 5.30, nightly and user made images For older images (even upgraded to 5.30 or later) manual update of the u-boot and the boot script is required

It's a good idea to not rely on those iozone numbers made with just a test size of 100MB but to also test with at least twice the amount of DRAM. If numbers differ significantly you can throw above numbers away (at least that's what I'm doing regularly when benchmarking since 'benchmarking gone wrong' is rule and not exception ): iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1 (if it's the same eMMC as on their other boards you'll end up with write 'performance' below 7 MB/s)

Especially if the image is somewhat older since with this commit few weeks ago we lowered DRAM clockspeed from 648 MHz to 624 MHz. If it's about nailing the problem down I would look at memtester and https://github.com/ehoutsma/StabilityTester too. BTW: memtester only requires an 'apt install memtester'.