tkaiser

You had. But since you switched to a different governor and those sysfs entries are created/removed dynamically they disappeared. As soon as you switch the governor /sys/devices/system/cpu/cpufreq/$governor will reappear. As a general information: we tried to move away from ondemand two years ago with kernel 4.7 when schedutil governor was introduced which should be a replacement for ondemand that is considered somewhat broken by kernel devs. Unfortunately with schedutil a lot of strange things happened (at least on ARM) so we were back at ondemand. Ondemand unlike other governors has some tunables that are important for many use cases: https://github.com/armbian/build/blob/52bef7ddf9d424eb65d831385714a9da66153078/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L71 The most important one for good storage performance is io_is_busy set to 1. If this is not set IO accesses are often way slower since cpufreq remains at a low value all the time instead of jumping to the maximum. Now we seem to have a problem with ondemand governor not switching to lower cpufreqs caused by a changed sampling_rate default (too low). So now we need feedback from users playing around with this value with different kernels. Simply edit /etc/init.d/armhwinfo and search for 'ondemand' there, then add the missing 'echo 200000 >${i}/sampling_rate' line, play around with the values and report back. If you use an Armbian nightly or switched to dev branch then you need to edit /usr/lib/armbian/armbian-hardware-optimization instead of /etc/init.d/armhwinfo.

By testing with second part of the aforementioned commit. As @BRSS discovered the sampling_rate value changed with some kernel version and that affects the governor's behaviour: https://forum.armbian.com/topic/6398-orange-pi-zero-cpu-and-load-issues-with-538/?tab=comments#comment-58057 (let's ignore the 'average load' problem for now since unrelated). So by testing through different values and this also with some older kernels we could try to come up again with settings that match everywhere. 'Legacy'/default kernels aren't that much of an issue since we use with sunxi kernels lower than 4.x the interactive governor (since ondemand sucks with Allwinner BSP kernels and interactive is the only reasonable choice). So it's really just testing through higher sampling_rate values with some kernel variants. Discussion should IMO better happen in the other thread (even if 'wrong' subforum).

I read about that 'workaround' but this one is no option as already explained in detail (since not behaving correctly with I/O loads -- switching to conservative trashes storage performance). It would be better if users would help testing instead of promoting broken workarounds.

Hi, I created a Tinkerboard OMV 4 image some while ago, we uploaded it untested (since 'OMV' just means Armbian's build system doing its job with a massive post processing script adding tons of stuff) but now got the report it doesn't boot. That's a bit surprising given that the image has been downloaded over a hundred times and no one complained so far. Deleting the image is the logical consequence but maybe someone here with a serial console can give it a try and report whether the board comes up or where it gets stuck at booting. http://kaiser-edv.de/tmp/jk4NM5/OMV_4_Tinkerboard.img.xz (with mainline kernel) or the default kernel variant from here: https://sourceforge.net/projects/openmediavault/files/OMV 4.x for Single Board Computers/ Thanks in advance!

AFAIK at least FriendlyELEC changed something on the boards to be able to distinguish between those board revisions with working voltage regulation and the older ones. They use a patched u-boot version where they implemented hardware detection and set DRAM clockspeeds based on this (at another location than standard u-boot). So if the above changes work maybe in the future we could extend support also by automatically detecting hardware revision in u-boot and then load the specific DT overlay in question (disclaimer: both DT and u-boot noob speaking here )

Historically the first H3 boards from Xunlong had an I2C accessible voltage regulator. Orange Pi One was the first with this primitive voltage regulation only switching between 1.1V and 1.3V. Allwinner's old H3 BSP contained code for I2C voltage regulators and the primitive mechanism with 1 pin (2 voltages) and 2 pins (4 voltages). The first H5 board (Orange Pi PC2) also used the advanced I2C accessible SY8106A chip but voltage regulation support in Allwinner's H5 BSP was broken and a little later they also removed it from later H3 BSP variants. That's the reason why Orange Pi PC2 with Allwinner's BSP kernel (3.10.65) never was able to reach high clockspeeds NanoPi NEO2 did not implement voltage regulation at all in the beginning The Libre Computer Tritium boards do the same FriendlyELEC could be convinced to give up on crappy Allwinner BSPs so they added voltage regulation to a later NEO2 revision, at the same time they redesigned other boards like NEO Plus2 (some Armbian devs have early revs without voltage regulation) or NanoPi M1 Plus2 (here they even use a SY8106A). Back to your overlays: great work! Thanks. If we find out that all affected boards use the same pin PL06 wouldn't it be nice to combine both overlays into one? Which boards are affected? You listed 'Nano Pi Neo2 v1.1, Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, Nano Pi Neo Plus2' but AFAIK the latter shouldn't be on the list since the regulator stuff for this board can be part of the normal DT and doesn't need an overlay. Then I've to admit that I'm not familiar with the way mainline implements throttling at all. Is the number of cooling-maps entries limited? When we started with our optimizations on A64 and H3 boards more than 2 years ago we added as much cpufreq/dvfs OPP and 'cooling-maps' nodes as possible since allowing cpufreq to avoid large jumps was key to success. When I first tested with the mainline implementation performance was significantly lower once throttling kicked in. We found that providing 48 MHz steps especially in that thermal region where throttling will happen afterwards will provide overall higher performance compared to a setup where cpufreq always switches between a very low and a very high value instead of choosing the optimum in between. But I guess we're limited here, right? Wrt the pin used. There's BPI M2+ H5 that uses PL01 with board revision 1.2 but fortunately we don't need to care about this board. And even if we had we could simply use a single DT for all board variants since this overheating fail used 1.3V on revision 1.1 (same hardware as BPi M2+ with H3 SoC)

I deleted removal of the symlink now: https://github.com/armbian/build/commit/52bef7ddf9d424eb65d831385714a9da66153078 (hopefully more people will test and report back, especiall wrt ondemand scheduler behaviour -- always remaining at max cpufreq with recent kernels)

That's the culprit. The sysfs node is present at boot but can not be read out for whatever reasons. So it's some sort of a timing problem. I added removal of the /etc/armbianmonitor/datasources/soctemp symlink to get 'nicer' output with 'armbianmonitor -m' some time ago but seems like this is counterproductive. Can you try to repeat the test after commenting this line?

Weird. You could add the following just below the '#!/bin/bash' line and then post the contents of /tmp/armbian-hardware-monitor-debug.txt after a reboot, then waiting 5 minutes and then stopping/starting the service again: exec 2>>/tmp/armbian-hardware-monitor-debug.txt set -x date

systemctl status armbian-hardware-monitor

This is as expected on most recent Armbian images with mainline kernel. I still don't get it: is there a problem or not? It should be set this way after each and every reboot as long as thermal support is available in the specific kernel branch.

Usually with Micro USB the problem is between PSU and board. More than 99% of all Micro USB cables are simply insufficient and were not made to transport more than 500mA. Jean-Luc ran into similar problems when reviewing the board (though using the vendor's own PSU with fixed cable which should probably be ok even if Micro USB is only rated for 1800mA max which is a joke if you want to attach host powered USB3 disks). Further readings: https://www.cnx-software.com/2018/07/14/roc-rk3328-cc-review-fast-storage-power-supply/ https://forum.armbian.com/topic/4767-powering-through-micro-usb/ https://www.cnx-software.com/2017/04/27/selecting-a-micro-usb-cable-to-power-development-boards-or-charge-phones/ https://forum.armbian.com/topic/5864-librecomputer-renegade-rk3328/?do=findComment&comment=54881

The script uses /sys/class/hwmon/hwmon0/temp1_input since this should be the 'usual place' with modern kernels. Is reading out the temperature working now or not ('cat /etc/armbianmonitor/datasources/soctemp')

cpufreq-set -g performance for i in 128 192 256 ; do openssl speed -elapsed -evp aes-${i}-cbc; done This (also 'OpenSSL 1.1.0f 25 May 2017' -- Debian Stretch) results in type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 95001.11k 300025.71k 628819.80k 900902.91k 1028759.55k 1039226.20k aes-192-cbc 90857.74k 269696.09k 520566.02k 699155.46k 775708.67k 780954.28k aes-256-cbc 88656.81k 251228.82k 456117.16k 587700.91k 640838.31k 644011.35k Now connecting an USB3 attached SSD and repeating: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 95060.44k 299314.65k 628529.15k 900353.02k 1028920.66k 1039018.67k aes-192-cbc 90838.22k 269684.97k 520050.86k 699034.62k 776033.62k 780004.01k aes-256-cbc 88611.06k 251042.15k 456075.01k 587704.32k 640884.74k 644541.10k 'armbianmonitor -u' output: http://ix.io/1hh1 (no 'Unexpected interrupt latency' occurences). I power the Renegade in a sane way: 5V/4A PSU feeding 5V via GPIO header. @jmandawg how do you power the board? Using the crappy Micro USB connector?

No. How does the output of the following look like? /bin/bash -x /usr/lib/armbian/armbian-hardware-monitor start

Then your image already uses /usr/lib/armbian/armbian-hardware-monitor and there the symlink should be created automatically at boot. Strange.

This is something that should happen automagically at boot. Can you please provide output from grep soctemp /etc/init.d/armhwinfo

Yes. And simply deactivating it won't help since you also need to modify /etc/fstab since our default settings use a commit interval of 10 minutes. So removing the commit setting and adding sync might provide some insights in the log... take care of reducing the life-time of your SD card after such changes.

Again: you won't find anything in any log if you suffer from usual hardware problems (they cause freezes/crashes, especially on 'el cheap' SBC and especially when powered by crappy Micro USB). Apart from that logging with latest Armbian is broken anyway (at least shutdown logging -- the relevant service is not executed at shutdown/halt/reboot target)

Feeling a bit stupid now since by looking through this thread I found my own test numbers made with Firefly image/kernel/settings: 940 Mbits/sec in both directions. So we have a problem somewhere in either Armbian or ayufan's kernel/settings.

Thanks for the report (you need to call h3disp prior to reboot if you replace script.bin). So we can use a single fex file and I hope the DT gets fixed upstream (just reported it in linux-sunxi IRC). Now have fun with off-topic babbling about card readers here in a device review thread (really unbelievable)...

It is. Once a Debian LTS release is EOL security maintainance moves away from security to LTS team and as such security.debian.org becomes obsolete with arm64 architecture: https://wiki.debian.org/LTS Removing the line from sources.list will stop the warning to appear. This affects all Jessie arm64 installations since a few weeks so most probably we can call this a FAQ soon... To be clear: Debian LTS support is only available for i386/amd64/armel/armhf architectures so arm64 is unsupported and as such we should even think about to remove all Jessie/arm64 images from download pages (or add at least a warning).

I don't think we need to distinguish any more. With settings for the v1.2 revision PL01 will be toggled on v1.1 boards but nothing will happen (given PL01 is not connected to anything important there -- maybe someone wants to look up schematics to have a look -- I'm just kidding of course ) @Tido : can you try the following with a legacy image on your board (I gave away almost all Allwinner boards in the meantime due to lack of interest): wget https://raw.githubusercontent.com/armbian/build/cd9eb6b6da2c95a2ab750a9acd07a55a84d56623/config/fex/bananapim2plus.fex mv /boot/script.bin /boot/script.bin.bak fex2bin bananapim2plus.fex /boot/script.bin reboot Then output from armbianmonitor -u after the reboot would be needed. In case no ARISC errors show up everything is fine and after adoption of paths (wrong as usual) this patch could be added to Armbian's build system by whoever feels interested.

It's the other way around, if the board would come up with 1.1V it would crash. And our modified settings would ruin performance and keep the board 'cold'. https://irclog.whitequark.org/linux-sunxi/2018-07-13#22574021; so I revert the change. After editing this mini post 8 times BPi folks even mention that software could use PL0 to distinguish between old and new variant. But honestly I don't care...

Yes, it's only available what's defined in DT. This is related to this topic. But please be careful: setting minimum cpufreq to really low values is counterproductive with some cpufreq governors since it will take a high amount of time to increase cpufreq when needed. @zador.blood.stained and me tested extensively two years ago with a lot of H3 boards and back then we found that setting boards to ~500 MHz minimum was the best compromise. When looking at temperatures or consumption there's literally zero difference between idling at 240 MHz or 480 MHz. The only important thing is DVFS (entering a state where the CPU is fed with lowest voltage possible -- so on those H3 boards with primitive voltage regulation most probably idle behaviour at 240 MHz and 816 MHz doesn't differ that much or at all). Keeping minimum clockspeed at a sensible high value is especially important when thinking about storage performance since some cpufreq governors don't count I/O activity as an indication to increase CPU clockspeeds. For example SD card performance on Tinkerboard with TinkerOS sucked but not with Armbian. Only real difference: the kernel allows to downclock to 200 MHz while with Armbian our cpufrequtils package keeps minimum clockspeed at 600 MHz. In Armbian we have special precautions for the ondemand governor: https://github.com/armbian/build/blob/52c71aba807f28e8325f324fba39f25e6991f7f2/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L70 It seems I need to add something to tune sampling_rate as @BRSS suggested above (seems something changed with 4.14). Currently testing with if [ -f /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency ]; then echo $(($(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency) / 10 )) >${i}/sampling_rate fi Feedback welcomed! Anyone willing to help please edit /etc/init.d/armhwinfo and add the above after the 'echo 10 >${i}/sampling_down_factor' line, reboot and report back.