tkaiser

By looking at the individual results it should be pretty obvious that at least the Blender test is all about DRAM performance. Just compare the 'overclocked' RPi 3 B+ numbers and eg. ODROID-C2 vs. Rock64. Memory throughput numbers here are useful for interpretation: https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ (the RK3328 device there has even faster DDR4 memory so this has to be taken into account).

Use /sbin/mount_cifs on your Linux box for SMB shares. If you mount them via GUI performance will be crappy (one of the many reasons why I hate 'Desktop Linux')

So called 'heartbeat' led trigger and the symptom that kernel could be loaded and runs fine.

Agreed!

Hmm... not sure what to do. I've no idea how many users are able or willing to solder this 'Q5 BSN20' thing so they can make use of DVFS instead of DFS and clock the H5 above 912 MHz. Would also be interesting whether Xunlong plans a new board revision with Q5 already soldered... I would prefer settings that allow to easily switch from 'no DVFS' to 'working DVFS'. Is /etc/defaults/cpufrequtils part of our BSP package?

Ok, then let's assume voltage regulation simply never worked on the Orange Pi H5 boards with SY8113B, right? Which would mean we should rather sooner than later limit them to 912 MHz max cpufreq... (or even 816 MHz to have some safety headroom?)

Yes, this is the first thing that should happen. We have now 3 reports of Orange Pi where this specific Mosfet is missing so it's either a batch of broken boards (no idea whether that's possible? Missing reel in the pick-and-place machine?) or an intentional change. If it's the latter then why using Orange Pi any more? @Igor are you still constantly in touch with Steven and can ask him?

Well, since Allwinner broke DVFS also on H3 SoCs with their latest BSP drop how do we have to deal with this? If Xunlong now starts to destroy voltage regulation on their H3 boards too how should we prevent user installations on new boards from crashing? BTW: if I understood @Da Xue correctly this (new BSP without DVFS support) is the primary reason for Libre Computer's Allwinner boards having no voltage regulation by design. To be honest: using and supporting Allwinner H series gets more and more irrelevant...

The Sunvell R69 stuff should work out of the box (maybe leds and other secondary peripherals need adjustments). I built images some time ago available through web.archive.org -- simply search the forum. If the R69 stuff works you can also use bin2fex or fex2bin to adjust fex stuff (again: search the forum) where it's needed. But this way you remain on the smelly 3.4 kernel. For mainline Linux you would need to adopt a device-tree file (same idea: start with the R69 and adopt changes via dtc tool contained in device-tree-compiler package).

https://www.cnx-software.com/2018/03/27/turris-mox-is-a-modular-router-with-wifi-ssd-lte-modem-ethernet-and-sfp-fiber-modules-crowdfunding/#comment-552639

OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV. Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097 And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).

Nope. Use crappy components on a board and this affects DRAM as well as CPU clockspeeds. Mentioning 'crappy'. It's like that: dram_clk = 576 pmuic_type = 0 max_freq = 1008000000 If these values are correct (who knows? Maybe the vendor just took someone else's work?) you might better choose an image for Sunvell R69 which is based on somewhat identical crappy hardware (no voltage regulation and unreliable DRAM). With any of the Orange Pi images that are made for better hardware (allowing to clock both CPU and DRAM higher) kernel panics are the best you can get.

Partially it could. If all CPU cores are busy doing stuff then adding another task might slow everything down (more tasks than resources). When throttling jumps in transfer speeds definitely decrease but it's unlikely this happened (I mentioned the thermal readouts only since I think they're too high). Again: check your dmesg output for 'SYN flooding'. If there's something in your network hammering the machine then for sure throughput of other services will then being bottlenecked by a single GbE connection. And no, I don't know what you had running on port 9090 or 8888 (the latter most probably being RPi-Monitor?)

Thank you! Nothing suspicious except your H2 running quite hot (76.0°C) and some messages talking about syn flooding. I would try to 'gently massage' the PCB to improve contact between SoC and enclosure (when I got my HC2 this helped to decrease temperatures a bit -- obviously a sign of thermal paste not applied that great). Cpufreq scaling works, you still run the old kernel and the OMV updates itself haven't change much. So I would better do some isolated tests (iozone for your storage and iperf3 to test between different hosts for networking anomalies).

Can you provide 'armbianmonitor -u' output please...

I fear you should invest some time into learning the basics first. 3.4.39 is not mainline and does also not use device-tree. The best source of information you have is sys_config.fex (that's HW description the 'Allwinner style'). There you should especially pay attention to the dram section and there clockspeed. You can also check for this with a running 3.4.39 kernel doing this cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq Our OS images for Orange Pi use mostly 624 MHz DRAM clockspeed which could be way too much for 'random H3 Android device' out there. To get an idea how fex files need to be (slightly) adjusted to become fully Armbian compliant look at the second commit here: https://github.com/armbian/build/commits/700c4011286dd52500979dc82501f5a782c7518f/config/fex/orangepi-r1.fex

IMO the best idea is to do a web search for 'mbuffer ssh' for some examples and explanations. Most probably mbuffer works fine without SSH being involved at all with your use case.

I would install mbuffer on your laptop, try again and report back.

Thank you for providing dev samples already weeks ago. We've been working 24/7 to support this awesome board from day one!

This is harmless. But I found a serious issue in nand-sata-install.log: Checking again for open files: apt.syste 1377 root 11w REG 179,1 0 35214 /var/lib/apt/daily_lock unattende 1411 root 4uW REG 179,1 0 35242 /var/lib/dpkg/lock http 2483 _apt 4u REG 179,1 4370166 37513 /var/cache/apt/archives/partial/g++-6_6.3.0-18+deb9u1_armhf.deb That means unattended-upgrades was running while the installation has been cloned with rsync which will result in a corrupted installation for sure. This is something that needs a fix in nand-sata-install anyway. Cloning a running system is always a problem but with a running install orgy in the background it must fail.

Please see how to increase boot verbosity: https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toogle-verbose-boot Do you have a serial console? That would be really helpful since it allows to record the boot process with increased boot verbosity. Then if the issue only occurs after you executed nand-sata-install can you take the SD card, access the rootfs and pastebin /var/log/armhwinfo.log and /var/log/nand-sata-install.log?

Can you try to capture the lines prior to the kernel panic. Without serial console it can become hard to diagnose this since without looking through a detailed log this becomes a job for mind readers

To somewhat close the chapter... Since my usual 'storage performance test setup' was lying around and the last RPi I own next to it I thought I do some quick iozone measurements. Once under-volted and one time with 'turbo mode' enabled (it was totally sufficient to replace my 20AWG rated Micro USB cable with a random one from the drawer -- sufficient to let voltage drop below 4.65V and activate 'frequency capping'). EVO840 SSD in JMS567 enclosure, latest RPi 4.9.80 ARMv7 kernel (no UAS), Armbian tweaks active since testing on the OMV image (improved IO scheduler settings and so on). Test call as usual: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Raspberry 2 @ 600 MHz (under-volted) random random kB reclen write rewrite read reread read write 102400 4 7369 8290 8481 8544 8132 8034 102400 16 17151 18160 18169 17947 17780 18290 102400 512 29496 29712 28776 28933 28884 29574 102400 1024 28866 29460 28840 28871 28801 29370 102400 16384 32732 34210 35102 34205 35089 34904 Raspberry 2 @ 900 MHz random random kB reclen write rewrite read reread read write 102400 4 10117 10628 10620 10645 10101 10669 102400 16 19907 21311 20776 21271 20627 21289 102400 512 29364 29938 29191 29249 29244 30150 102400 1024 30277 30554 29603 29379 29564 30342 102400 16384 34284 35908 36678 36675 36232 36277

On your screenshot the kernel panic happens with a 4.13 kernel while now after you applied all updates you're on 4.14. So my assumption is that something went wrong before (you said 'I performed apt update && apt upgrade -y and reboot the system' -- but then you should've also been running with 4.14)

Thank you. I was looking for underpowering but that's totally fine (5.19V with connected SSD): ### Boot system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 09:54:20: 960MHz 1.05 76% 40% 32% 0% 3% 0% 37.0°C 29.4°C 5.19V 0/6 09:54:21: 960MHz 1.20 73% 31% 36% 2% 3% 0% 37.1°C 29.2°C 5.26V 0/6 09:54:22: 960MHz 1.20 35% 28% 3% 2% 1% 0% 36.3°C 28.7°C 5.23V 0/6 09:54:23: 960MHz 1.20 24% 16% 0% 2% 5% 0% 35.6°C 28.3°C 5.25V 0/6 09:54:25: 960MHz 1.20 15% 9% 0% 1% 4% 0% 35.5°C 28.5°C 5.22V 0/6 Please note that you're now running with 4.14.14 (as expected) while you were on 4.13 before which is a bit weird given that you installed all updates.