znoxx Posted December 13, 2018 Posted December 13, 2018 I think I have 1.1 And I use Armbian only, no other distros. It just works :). I've even disabled updates since everything looks pretty stable. My cluster : http://znoxx.me/2018/11/08/table-cluster/ :) 0 Quote
Seasalt Posted December 14, 2018 Posted December 14, 2018 11 hours ago, znoxx said: My armbian "cluster" works 24x7 with full load Znoxx, What is your Armbian cluster? and what does it do? I have been seriously thinking about the FUN of building a cluster but I can not think of a use or purpose that ? PS have you bench-marked your Orange Pi PC2 and or cluster? Seasalt 0 Quote
znoxx Posted December 14, 2018 Posted December 14, 2018 @Seasalt, not sure I've got the question "What is your cluster" -- link I posted do have some pics and there is a "translate" button in menu (better than nothing). About cluster purpose -- currently it it mining some Verium crypto. Before I tried Apache Spark, for example. But not really successfull due to faulty microSDs and large number of read/write. Regarding benchmark - in mining (hashrate) it is comparable to e.g. core i5..i7, but well -- it consumes much less energy. E.g. 60..70 watts vs 150..200. I was inspired by this guy http://picocluster.com -- but my setup is much more cool :)). I'm using custom PCB to drive ATX PSU and fans. 0 Quote
svts Posted December 14, 2018 Posted December 14, 2018 @znoxx Nice job! I like the way how it looks, handmade devices have their own charm! :) So the debug proccess is still in process. I tried u-boot 2017.11 but got unfortunately no success. Would you please check "dmesg" of one of yours OPI PC2? Thank you in advance. The problem is it's almost impossible to notice the crash when there's no serial cable attached nor display as system recovers it but also notices in dmesg. Spoiler [ 219.123436] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 [ 219.132368] Mem abort info: [ 219.135292] ESR = 0x96000004 [ 219.138419] Exception class = DABT (current EL), IL = 32 bits [ 219.144427] SET = 0, FnV = 0 [ 219.147569] EA = 0, S1PTW = 0 [ 219.150830] Data abort info: [ 219.153734] ISV = 0, ISS = 0x00000004 [ 219.157667] CM = 0, WnR = 0 [ 219.160744] user pgtable: 4k pages, 48-bit VAs, pgdp = 0000000022abd91e [ 219.167460] [0000000000000088] pgd=0000000000000000 [ 219.172458] Internal error: Oops: 96000004 [#1] SMP [ 219.177346] Modules linked in: zstd zram sun8i_codec_analog snd_soc_hdmi_codec snd_soc_simple_card sun8i_adda_pr_regNmap sun4i_i2s sun4i_codec snd_soc_simple_card_utils snd_soc_core snd_pcm_dmaengine snd_pcm cpufreq_dt snd_timer sun4i_gpadc_iio industrialio thermal_sys sunxi_cir rc_core snd w1_therm soundcore w1_gpio wire lima sy8106a_regulator gpu_sched ttm dw_hdmi_i2s_audio dw_hdmi_cec uas realtek [ 219.212663] CPU: 2 PID: 2473 Comm: grep Not tainted 4.19.8-sunxi64 #5.67.181213 [ 219.219971] Hardware name: Xunlong Orange Pi PC 2 (DT) [ 219.225120] pstate: 00000005 (nzcv daif -PAN -UAO) [ 219.229945] pc : _get_random_bytes+0xac/0xe8 [ 219.234255] lr : _get_random_bytes+0xac/0xe8 [ 219.238547] sp : ffff00000d26bbc0 [ 219.241876] x29: 0000000000000000 x28: ffff80002a676100 [ 219.247203] x27: 0000000000000002 x26: ffff80002ff85780 [ 219.252527] x25: ffff80003634f000 x24: ffff800033e2e900 [ 219.257848] x23: 0000000000000010 x22: ffff000008d688c8 [ 219.263176] x21: ffff00000d26bc08 x20: 0000000000000010 [ 219.268494] x19: ffff00000d26bd58 x18: 0000000000000000 [ 219.273811] x17: 00000000cf0ed6af x16: 000000009759a261 [ 219.279135] x15: 00000000846c09cb x14: 00000000e1321b33 [ 219.284464] x13: 00000000ab8ed928 x12: 00000000e3b80007 [ 219.289786] x11: 000000005ceb0788 x10: 000000003ce02806 [ 219.295107] x9 : 00000000c61535a9 x8 : ffff00000d26bc48 [ 219.300427] x7 : 0000000000000000 x6 : ffff00000d26bc08 [ 219.305757] x5 : ffff800033d5e400 x4 : 0000000000000008 [ 219.311088] x3 : 0000000000000030 x2 : 0000000000000008 [ 219.316408] x1 : 0000000000000000 x0 : ffff00000d26bc08 [ 219.321738] Process grep (pid: 2473, stack limit = 0x000000004c1dba41) [ 219.328266] Call trace: [ 219.330732] _get_random_bytes+0xac/0xe8 [ 219.334662] Code: d2800801 aa1503e0 912322d6 940ed73a (f94047a1) [ 219.340765] ---[ end trace 71540e1e95143ba8 ]--- I tried ATX power supply as well - so got same problem and also soldered 1000uF 10v capacitor directly to power supply connector to be sure there's no power fluctuation because of long cables but the problem still persists. 0 Quote
znoxx Posted December 14, 2018 Posted December 14, 2018 @svts Here is dmesg from 2 nodes. One bought long time ago: https://pastebin.com/Q0As9JTh And second from node which was recently replaced due to dead Ethernet (still not sure, that I picked right node, but anyway -- 2 dmesgs better than one): https://pastebin.com/8s91VAuU Hope it will help you. I still have a strong feeling, that the problem is inside hardware (RAM). May be it makes sense to order new one from official store@Aliexpres ? Just to be sure. I can bet, it will arrive faster, than you will debug the thing... 0 Quote
svts Posted December 14, 2018 Posted December 14, 2018 @znoxx Thank you. Well actually I did just what you said. When I started expecting some issues I ordered a new board and when it arrived I confimed that the problem did persist. Technically it's possible that the board I ordered has the same buggy parts but... it's almost unbelievable you know :) 0 Quote
Seasalt Posted December 14, 2018 Posted December 14, 2018 4 hours ago, znoxx said: I posted do have some pics Wow that is a really cool cluster. Well done 0 Quote
znoxx Posted December 14, 2018 Posted December 14, 2018 @Seasalt, thanks! I'm working on new version, with OpiOne+ (faster!! newer :)) and fitted into standard microATX case. Want something more standard and reproducible. @svts Hmm... You are right. I even upgraded whole bunch of board to latest armbian to check if it is an issue of latest builds. But looks like no. ~1 hour 100% load, no "mayday mayday" zno@cluster:~$ for i in `seq 0 9`; do ssh node$i uptime; done 10:47:44 up 1:02, 0 users, load average: 4.01, 4.03, 4.00 10:47:45 up 1:01, 0 users, load average: 4.08, 4.02, 4.01 10:47:46 up 1:01, 0 users, load average: 4.18, 4.06, 4.02 10:47:47 up 1:00, 0 users, load average: 4.00, 4.01, 4.00 10:47:48 up 1:00, 0 users, load average: 4.00, 4.00, 3.99 10:47:50 up 59 min, 0 users, load average: 4.02, 4.05, 4.00 10:47:51 up 59 min, 0 users, load average: 4.00, 4.00, 3.98 10:47:52 up 58 min, 0 users, load average: 4.16, 4.09, 4.02 10:47:54 up 58 min, 0 users, load average: 4.00, 4.05, 4.00 10:47:55 up 57 min, 0 users, load average: 4.00, 4.01, 4.00 Consider "yet another lame idea". Can you try to power stuff via GPIO pins, not via barrel connector ? I used 2 wires from standard Ethernet patch cord. Just as experiment. 0 Quote
svts Posted December 14, 2018 Posted December 14, 2018 @znoxx Maybe it depends on what it is running... Would you please to run my test script there if it's possible? Spoiler #!/bin/bash while true; do date +%H:%M:%S | tr -d '\n' for I in `seq 5 10`; do timeout $(($I/2)) cat /dev/zero > /dev/null & timeout $(($I/2)) cat /dev/zero > /dev/null & cat /sbin/`ls -S /sbin | head -n1` | grep 123 > /dev/null & done top -d0 -n2 | grep 'Cpu' | tail -n1 | sed 's/%Cpu(s)\://' | tr -d '\n' echo -n " $(($((`cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq 2>/dev/null`+0))/1000))MHz" echo -n " $(($((`cat /sys/class/thermal/thermal_zone0/temp 2>/dev/null`+0))/1000))C" echo -n " " ps -eF | grep -E '[0-9]{2} cat' | awk '{print $7}' | tr -d '\n' wait echo -n " b>" read -t1 BREAK echo "B" if dmesg | tail -n20 | grep '\---\[ end trace'; then break; fi if [ ! -z "$BREAK" ]; then break; fi done This script breaks the system in like 5 to 15 minutes usually. Thank you! 0 Quote
znoxx Posted December 14, 2018 Posted December 14, 2018 @svts see results here: https://pastebin.com/5CXyyuQm Script runned for approx. 10 minutes, giving message presented in the paste (I've added only last 3 minutes I guess because "screen" truncated it - hope it's enough) Also dmesg has swap/oom errors and I see docker container is restarting, but it was done during high load to ram/swap/cpu. Note to myself: invest into better microsd cards :). 0 Quote
svts Posted December 17, 2018 Posted December 17, 2018 So the problem was solved! sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr The reason of crashes was DRAM PLL value which seems too high for the boards I have. Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value. I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore. The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr. After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes. Thanks everybody who helped me to find a solution. Special thanks to @znoxx for testing and logging :) 2 Quote
znoxx Posted December 17, 2018 Posted December 17, 2018 @svts, u digged great thing. U told me, that boards were bought not from Xunlong shop, but from some third-party guys. Good thing for Xunlong -- their products are being copied =) with cheaper components (which is sooo aliexpress -typical). Bad things for most of us -- when you buy a board from a "local supplier" or cheaper than in official store, most probably you can bump into a "fake one". Because supplier cares about margin/income/whatever, not about the quality of product. Probably in Europe/US the situation is better, but in countries like Russia it's pretty typical. So time to say "beware of fake Orange Pi's " ? 0 Quote
Magnets Posted January 11, 2019 Posted January 11, 2019 On 12/17/2018 at 5:35 AM, svts said: So the problem was solved! sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr The reason of crashes was DRAM PLL value which seems too high for the boards I have. Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value. I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore. The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr. After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes. Thanks everybody who helped me to find a solution. Special thanks to @znoxx for testing and logging Great work! I have the same problem with a PC 2 which came direct from the manufacturer Your script has some unicode characters so I removed them: sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr 0 Quote
Seasalt Posted February 16, 2019 Posted February 16, 2019 On 3/24/2018 at 5:28 PM, Igor said: This feature cost 30.000 EUR and will be implemented free of charge when it is delivered You can find detail info on that page. Does anyone know if Armbian will include the new Allwinner H5 video Unit enhancements in Linus's Mainline Kernel 5.0 "AKA 4.21" that came out last week. If so what would the time line be to have the enhancements in Armbian Orange pi PC2?. Currently I believe the Orange Pi PC2 Armbian OS is at version 4.19 mainline kernel. 0 Quote
Igor Posted February 16, 2019 Posted February 16, 2019 4 hours ago, Seasalt said: that came out last week. ... and my task list tells me that I can check on this once by the end of this year. Perhaps not even this year. But perhaps somebody will solve this sooner - project is open. You can do this or you can do something to lower the pressure on our small resources: https://www.armbian.com/get-involved 0 Quote
lopau Posted March 26, 2019 Posted March 26, 2019 Hi I've noticed that thermal throttling doesn't work on the OPi PC2. I'm on 5.75. I've tried armbianmonitor -m but it doesn't give me the CPU frequency: $ armbianmonitor -m Running unprivileged. CPU frequency will not be displayed. Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 14:45:40: --- 0.11 12% 0% 11% 0% 0% 0% 54.9°C 0/15 14:45:45: --- 0.10 0% 0% 0% 0% 0% 0% 55.3°C 0/15 14:45:50: --- 0.09 0% 0% 0% 0% 0% 0% 55.2°C 0/15^C Nonetheless, I get the frequency using cpufreq-info. It remains at 1.1GHz even when the temperature is around 88C. The board just shuts down when it hits 90C. Shouldn't it thermal throttle? My /etc/default/cpufrequtils looks like this: # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=120000 MAX_SPEED=1400000 GOVERNOR=ondemand Anyone know why thermal throttling isn't working? Thanks 0 Quote
martinayotte Posted March 26, 2019 Posted March 26, 2019 12 minutes ago, lopau said: Running unprivileged. CPU frequency will not be displayed. It seems that you are not running "armbianmonitor -m" as root ... 0 Quote
lopau Posted March 26, 2019 Posted March 26, 2019 1 hour ago, martinayotte said: It seems that you are not running "armbianmonitor -m" as root ... You're right. Here's the new output: $ sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:55:19: 1368MHz 0.82 4% 0% 4% 0% 0% 0% 58.2°C 0/15 16:55:25: 240MHz 0.76 0% 0% 0% 0% 0% 0% 58.8°C 0/15 16:55:30: 240MHz 0.70 4% 1% 1% 0% 2% 0% 63.2°C 0/15 16:55:35: 120MHz 0.64 1% 0% 0% 0% 0% 0% 60.1°C 0/15 16:55:41: 1104MHz 0.99 70% 1% 69% 0% 0% 0% 75.1°C 7/15 16:55:48: 1104MHz 1.23 100% 0% 99% 0% 0% 0% 81.6°C 7/15 16:55:55: 1104MHz 1.73 100% 0% 99% 0% 0% 0% 86.9°C 7/15Connection to 192.168.100.134 closed by remote host. It's clear that the CPU frequency isn't being throttled down even when the temperature was approach 90C. Is this normal for the PC2? 0 Quote
Igor Posted March 27, 2019 Posted March 27, 2019 14 hours ago, lopau said: It's clear that the CPU frequency isn't being throttled down even when the temperature was approach 90C. Is this normal for the PC2? That isn't normal and thermal throttling could be broken / not tuned well. armbianmonitor -u would give us better picture over the problem without trying to replicate. 0 Quote
lopau Posted March 28, 2019 Posted March 28, 2019 On 3/27/2019 at 5:54 PM, Igor said: That isn't normal and thermal throttling could be broken / not tuned well. armbianmonitor -u would give us better picture over the problem without trying to replicate. Can I ask at what temperature should thermal throttling start to kick in? I'm now using a more powerful PSU (5V 3A) and it's still the same. Here's my output: http://ix.io/1EHF Cheers 0 Quote
nobitakun Posted March 28, 2019 Posted March 28, 2019 I paste my log since I'm having also this issue. I'm trying to compile something and the CPU is crazy, every 5 minutes restart. http://ix.io/1EJ4 Armbian 5.75 Stretch, last build just installed today in a fresh microsd. Can these lines be the source of the problem? [ 4.404838] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-17 [ 4.576372] thermal thermal_zone0: failed to read out thermal zone (-110) [ 4.576424] OF: /thermal-zones/cpu-thermal: arguments longer than property [ 4.576435] thermal thermal_zone2: failed to read out thermal zone (-110) I hope this gets fixed as soon as possible. Thanks for your hard work! :) 0 Quote
lopau Posted March 29, 2019 Posted March 29, 2019 Just an update: I thought it might be just that board, so I've just tried another PC2 unit but I'm not getting thermal throttling on it either. It also shuts down around 90C. 0 Quote
houldsg Posted April 3, 2019 Posted April 3, 2019 I'm having the same issue as well. I had to stick a small fan on the case for now. Under load, the frequency never drops below 1104MHz. I'm a bit of a noob but I've been trying to investigate (so let me know if I'm way off). houldsg@orangepipc2:~$ uname -a Linux orangepipc2 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 aarch64 aarch64 GNU/Linux houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/ available_policies cdev0_weight k_d k_pu policy subsystem/ trip_point_0_hyst trip_point_1_hyst type cdev0/ emul_temp k_i mode power/ sustainable_power trip_point_0_temp trip_point_1_temp uevent cdev0_trip_point integral_cutoff k_po offset slope temp trip_point_0_type trip_point_1_type houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 65000 houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp 90000 65 degrees is when the frequency drop to 1104. Does trip point 0 trigger a particular frequency (1104)? Should there be more trip points or is the throttling handled by another mechanism? 1 Quote
znoxx Posted April 4, 2019 Posted April 4, 2019 Did throttling behaved differently on previous Armbian builds ? And may be it is possible to try e.g. thermald - https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon ? 0 Quote
houldsg Posted April 4, 2019 Posted April 4, 2019 It didn't happen to me on the previous image I was running (ARMBIAN 5.32.170803 nightly Ubuntu 16.04.5 LTS 4.11.10-sun50iw2) When I have some time, I'll put an older version on an sd card and prove it with data. Can anyone else identify the version they noticed the change in behavior? 0 Quote
znoxx Posted April 9, 2019 Posted April 9, 2019 Looks like I also bumped this issue... But only on one PC2 from 12(!) First things first: http://ix.io/1FMV - armbian log Here is my armbianmonitor -m output: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 21:11:03: 120MHz 0.21 1% 0% 0% 0% 0% 0% 67.2°C 7/15 21:11:08: 120MHz 0.19 1% 0% 0% 0% 0% 0% 69.0°C 7/15 21:11:13: 120MHz 0.17 1% 1% 0% 0% 0% 0% 69.4°C 7/15 21:11:19: 120MHz 0.16 1% 0% 0% 0% 0% 0% 70.6°C 7/15 21:11:24: 120MHz 0.15 1% 0% 0% 0% 0% 0% 70.8°C 7/15 21:11:29: 120MHz 0.13 1% 0% 0% 0% 0% 0% 71.6°C 7/15 21:11:34: 120MHz 0.12 1% 0% 0% 0% 0% 0% 71.4°C 7/15 21:11:39: 120MHz 0.11 0% 0% 0% 0% 0% 0% 70.9°C 7/15 21:11:45: 120MHz 0.10 0% 0% 0% 0% 0% 0% 70.4°C 7/15 The only difference from my other 11 boards - it assembled in 2017. I strongly suspect the hardware. I have same heatsink applied with same thermal grease. When I put microSD in another board - temperature is about 35..39 when idle. This board shows about 70 when idle!! May be some voltage regulator is fried ? I also tried svts's magic command to reduce dram speed, but things are worse. Now I see 80C when idle What else to add: C.St is permanently 7/15. On other boards it is mostly 0/15 on idle. I have seen only one faulty board before (except ones I accidentally fried with 12v ) - Ethernet was dying during a week, then just stopped working. But It works with usb ethernet and usb wifi in another project. Any ideas so far ? And thanks in advance for your help. 0 Quote
Igor Posted April 10, 2019 Posted April 10, 2019 11 hours ago, znoxx said: May be some voltage regulator is fried ? Yes, it looks like some hardware malfunction. If only this one is behaving this way, simply throw it away and move on. 0 Quote
znoxx Posted April 10, 2019 Posted April 10, 2019 3 hours ago, Igor said: If only this one is behaving this way, simply throw it away and move on. Yeah, already did and ordered a replacement. But 2 things still are still curious here: 1) My "symptoms" a really look like lopau's case. 2) This board may be one not from manufacturer, but bought locally. 0 Quote
bschwehn Posted April 10, 2019 Posted April 10, 2019 (edited) On 3/28/2019 at 4:36 PM, nobitakun said: [ 4.404838] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-17 [ 4.576372] thermal thermal_zone0: failed to read out thermal zone (-110) [ 4.576424] OF: /thermal-zones/cpu-thermal: arguments longer than property [ 4.576435] thermal thermal_zone2: failed to read out thermal zone (-110) FWIW, these messages seem to go away when building the dev branch without patch /patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch Not sure if this patch is compatible with the changes already done in the megous branch (like this patch) Still, throttling is done only down to 1104 MHz (not an issue for me personally, for me this throttle is enough for mine to not go above 81C @100% CPU usage for 10 minutes). Edit: Looks like I have it working now. I have basically added the patch ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch directly to linux-mainline/orange-pi-5.0/arch/arm/boot/dts/sunxi-h3-h5.dtsi (instead of /arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi) Spoiler thermal-zones { cpu-thermal { /* milliseconds */ polling-delay-passive = <250>; polling-delay = <1000>; thermal-sensors = <&ths>; trips { cpu_warm: cpu_warm { temperature = <55000>; hysteresis = <2000>; type = "passive"; }; cpu_hot_pre: cpu_hot_pre { temperature = <60000>; hysteresis = <2000>; type = "passive"; }; cpu_hot: cpu_hot { temperature = <70000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_pre: cpu_very_hot_pre { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot: cpu_very_hot { temperature = <85000>; hysteresis = <2000>; type = "passive"; }; cpu_crit: cpu_crit { temperature = <90000>; hysteresis = <2000>; type = "critical"; }; }; cooling-maps { cpu_warm_limit_cpu { trip = <&cpu_warm>; cooling-device = <&cpu0 THERMAL_NO_LIMIT 2>; }; cpu_hot_pre_limit_cpu { trip = <&cpu_hot_pre>; cooling-device = <&cpu0 2 3>; }; cpu_hot_limit_cpu { trip = <&cpu_hot>; cooling-device = <&cpu0 3 4>; }; cpu_very_hot_pre_limit_cpu { trip = <&cpu_very_hot_pre>; cooling-device = <&cpu0 5 6>; }; cpu_very_hot_limit_cpu { trip = <&cpu_very_hot>; cooling-device = <&cpu0 7 THERMAL_NO_LIMIT>; }; }; }; }; Not sure why that should make a difference, but throttling now seems to take the trips I have configured (though it seems to use a different cooling map: ramp up: Spoiler Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 18:26:30: 1368MHz 0.86 13% 1% 3% 0% 8% 0% 48.9°C 0/15 18:26:36: 1296MHz 1.12 100% 0% 100% 0% 0% 0% 56.0°C 2/15 18:26:43: 1296MHz 1.35 100% 0% 100% 0% 0% 0% 58.4°C 2/15 18:26:49: 1296MHz 1.83 100% 0% 100% 0% 0% 0% 60.7°C 5/15 18:26:56: 1296MHz 2.00 100% 0% 100% 0% 0% 0% 60.7°C 5/15 18:27:02: 1200MHz 2.16 100% 0% 100% 0% 0% 0% 60.8°C 5/15 18:27:09: 1200MHz 2.52 100% 0% 99% 0% 0% 0% 61.6°C 5/15 18:27:15: 1200MHz 2.64 100% 0% 100% 0% 0% 0% 62.4°C 5/15 18:27:22: 1200MHz 2.75 100% 0% 100% 0% 0% 0% 63.1°C 5/15 18:27:28: 1200MHz 3.01 100% 0% 99% 0% 0% 0% 63.7°C 5/15 18:27:35: 1200MHz 3.09 100% 0% 99% 0% 0% 0% 64.1°C 5/15 18:27:41: 1200MHz 3.17 100% 0% 100% 0% 0% 0% 64.9°C 5/15 18:27:48: 1200MHz 3.23 100% 0% 100% 0% 0% 0% 66.0°C 5/15 18:27:54: 1200MHz 3.43 100% 0% 100% 0% 0% 0% 66.3°C 5/15 18:28:01: 1200MHz 3.47 100% 0% 100% 0% 0% 0% 66.8°C 5/15 18:28:07: 1200MHz 3.51 100% 0% 99% 0% 0% 0% 67.4°C 5/15 18:28:14: 1200MHz 3.66 100% 0% 100% 0% 0% 0% 67.9°C 5/15 18:28:20: 1200MHz 3.69 100% 0% 99% 0% 0% 0% 68.7°C 5/15 18:28:27: 1200MHz 3.72 100% 0% 100% 0% 0% 0% 69.4°C 5/15 18:28:33: 1104MHz 3.83 100% 0% 100% 0% 0% 0% 69.5°C 5/15 18:28:40: 1200MHz 3.85 100% 0% 100% 0% 0% 0% 70.0°C 5/15 18:28:46: 1200MHz 3.86 100% 0% 99% 0% 0% 0% 70.0°C 5/15 18:28:53: 1200MHz 3.87 100% 0% 100% 0% 0% 0% 70.0°C 5/15 18:28:59: 1200MHz 3.97 100% 0% 100% 0% 0% 0% 70.2°C 7/15 18:29:06: 1104MHz 3.97 100% 0% 99% 0% 0% 0% 70.2°C 7/15 18:29:13: 1104MHz 3.97 100% 0% 100% 0% 0% 0% 70.2°C 7/15 18:29:19: 1104MHz 4.05 100% 0% 99% 0% 0% 0% 70.7°C 7/15 after insulating the board to get the temperature up: Spoiler 18:59:31: 960MHz 8.43 100% 0% 99% 0% 0% 0% 84.8°C 10/15 18:59:39: 960MHz 8.39 100% 0% 99% 0% 0% 0% 85.2°C 12/15 18:59:49: 960MHz 8.41 100% 0% 99% 0% 0% 0% 84.6°C 10/15 18:59:57: 960MHz 8.42 100% 0% 99% 0% 0% 0% 84.8°C 10/15 19:00:05: 960MHz 8.38 100% 0% 99% 0% 0% 0% 85.1°C 10/15 19:00:15: 648MHz 8.40 100% 0% 99% 0% 0% 0% 85.1°C 12/15 19:00:24: 960MHz 8.41 100% 0% 99% 0% 0% 0% 84.4°C 10/15 19:00:33: 960MHz 8.42 100% 0% 99% 0% 0% 0% 83.8°C 10/15 19:00:42: 960MHz 8.43 100% 0% 99% 0% 0% 0% 85.3°C 12/15 19:00:51: 960MHz 8.44 100% 0% 99% 0% 0% 0% 84.8°C 10/15 19:01:00: 648MHz 8.41 100% 0% 99% 0% 0% 0% 84.7°C 10/15 removing insulation lets temp drop again, and freq rise: Spoiler 19:05:19: 960MHz 6.03 90% 0% 89% 0% 0% 0% 83.8°C 10/15 19:05:28: 960MHz 6.40 100% 0% 100% 0% 0% 0% 82.5°C 10/15 19:05:37: 960MHz 6.72 100% 1% 98% 0% 0% 0% 80.7°C 7/15 19:05:45: 960MHz 6.83 100% 0% 99% 0% 0% 0% 80.1°C 10/15 19:05:53: 1104MHz 7.08 100% 0% 99% 0% 0% 0% 74.5°C 7/15 19:06:02: 1104MHz 7.30 100% 0% 100% 0% 0% 0% 72.0°C 7/15 Edited April 10, 2019 by bschwehn 3 Quote
znoxx Posted April 11, 2019 Posted April 11, 2019 14 hours ago, bschwehn said: Looks like I have it working now. This is great. Any chances to see this functionality in stable version of Armbian in visible period of time ? Thanks! P.S. Is this applicable for Allwinner H6 boards ? 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.