Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by ag123

  1. nope, i'm referring to the non-responding sshd, rpi-monitor freezes etc. that seemed to be alleviated selecting a vm.swappiness that is moderate say 50 etc
  2. after some searches i've only found a related but different issue https://github.com/armbian/build/issues/219 that relates mainly to kswapd taking 100% cpu - found quite a few instances in google searches not related to armbian. that particular issue seemed to be alleviated by vm.swappiness=0 but given the rather large lapse of time that issue is raised in 2016, and that it is for a different kernel 3.4.x it may not be directly relevant i think for the time being selecting a vm.swappiness in a mid range between 0 to 100 seem to alleviate related issues surfaced currently
  3. i won't be able to prove this easily, but if setting vm-swapiness to values less than 100 alleviates the issue, could it point to some possible issues related to or with zram? some google searches draw a blank as various similar issues are found but not identical to this, i.e. that zram isn't specifically mentioned. the other thing would be that it may be necessary to have the oom killer log the processes killed into /var/log/messages (i.e. by syslog or journald) for post mortem analysis of what actually happened, e.g. is sshd literally killed? i think oom killer currently only logs to dmesg, which means that the traces are lost once the board/soc is reset / restarted. i'm not too sure where such logs could be configured to be captured (kswapd?) such that if a paged out / swapped memory could not be restored the event be logged in syslog etc
  4. i think the issue about the vm.swapiness is that some of the processes, e.g. sshd after it is swapped out i.e. not resident in memory, may not respond or respond too slowly to connects over the network. i.e. that for some reason, external connects did not initiate a swapped out process image to be reinstated in memory in a normal manner if that's the case any attempts to connect over ssh fails reducing vm.swapiness in this case makes it more likely that sshd remains resident in memory rather than being swapped out, hence it alleviates the problem, but this likely won't resolve it entirely
  5. i think the somewhat elevated temperatures of say 70-75 deg C on H3 socs can be tolerated. the main trouble is that many of these boards ships without a heatsink the main thing about running at these temperatures is that the board needs to run in a well ventilated environment e.g. that it should not be enclosed in a box that limits simple convection heat transfer (i.e. 70-75 deg should be an upper load limit and temperatures must stabilise at this range during high loads and must not increase) I've an orange pi one that i found rather commonly runs at those temperatures without a heatsink, i'd imagine it may even be possible for it to goto boiling point 100 deg C and that the soc still runs but that to prevent damage, it would be necessary to throttle the frequency (e.g. reduce to 400mhz) and lower the voltages (reduce to as low as is possible e.g. below 1.1v if possible) at those temperatures. but a shutdown should be unnecessary but that 70-75 deg C should be considered 'normal' operating temperatures for H3 socs running at 1.2ghz when under high loads the situation can be improved quite a bit even with a rather small heat sink especially at the higher temperatures https://forum.armbian.com/topic/8203-orangepione-h3-an-experiment-with-small-heatsink/ in particular at the higher temperatures 70-75 deg could be rather easily reached in hot summer temperatures as heat transfer is a function of temperature differences vs ambient temperatures. a heat sink needs to be combined with good ventilation to remove all that heat and as in my experiment, heat sink + *good ventilation* prevents the soc from reaching the higher temperatures and that at steady state it lets the soc run at a marginally lower temperature than without a heat sink the problem i've with the orange pi h3 socs is that *after* the os is shutdown, the h3 soc and the board can overheat to such extreme that temperatures is well above 100 deg C, i almost have a board going up in fire. the only safe / precautionary way for now is to disconnect power once the status led indicates that the os has shutdown and do not issue a shutdown remotely if you can't unplug power from the board
  6. unfortunately no thanks to the big brand companies who brought the r-pi and tinkerboard (shudder) to the masses, for some reason, some brand companies seem to think micro-usb for powering a 10 watts or more board should be adequate, i'd guess that's why the board is designed that way in the first place on another note i went for an orange pi choosing between that and tinkerboard as partly due to price and that for those orange pi boards i bought, they come with their own dc barrel jack connectors, it is simply better for a bit more board real estate
  7. oh well, i didn't realise this rather nice tool exists, i guess i've been pretty old school as before i get to know armbian, many things used to be you are on your own, and dd is one of the tools that's just there https://etcher.io/
  8. just like to share my 2 cents as i'm using 5.59 Debian stretch image on Orange Pi PC if you have been using the 'old' images e.g. 3.x series, that is quite different from stretch (i've not tried bionic) which uses 4.x kernels. the 4.x kernels are mainline linux kernels. the old 3.4 kernels uses some of the binary blobs like FEX etc distributed by Allwinner et.al. 4.x kernels are mainline linux kernels and FEX is not there as FEX Is propriety and the binary blobs is close sourced. 4.x mainline kernels has some of the old 3.x functionality reverse engineered open sourced and the features are pretty functional but not all of it. i've used the 5.59 ubuntu stretch (mainline kernel 4.14.65 image for orange pi pc and do note that it is a cli (command line based) image HDMI works for me in 5.59 Ubuntu Stretch mainline image, connect a usb keyboard and mouse to work on it like a PC i'm not too sure if the Orange Pi PC you have bought a year back is after all the same as that i bought just recently, but based on the specs i think it should be pretty much the same. I'm not too sure if things may have changed between the year. If things are the same, install the image on a new (or different) SD card (i work in linux and simply did dd if=Armbian_5.59_Orangepipc_Debian_stretch_next_4.14.65.img of=/dev/<the sdcard device> bs=1m to write the image to the sd card. and boot that on the Orange Pi PC, it should boot and should leave you on the command prompt in HDMI asking you to logon. be a little careful with the initial password changes as you would need the new changed passwords after the initial logon and user creation. i made some mistakes and got locked out initially. ssh needs to be setup anew as the os is reinstalled. i think if you are used to access the sbc as orangepipc.local. you may find that ping etc didn't turn up orangepipc.local. i found out that that is mainly because avahi-daemon (i.e. mdns) is not installed on the orange pi pc. what i did is to do apt-cache search avahi on the sbc and install the avahi-daemon (e.g. apt-get install avahi-daemon) and subsequently i'm able to ping my board as orangepipc.local connected on the ethernet. i'm not using any wireless dongle. after that ping and ssh to the hostname orangepipc.local works. if you want to install the desktop, you need to run the commands: - apt-get upgrade armbian-config followed by - armbian-config as root and there is an option to install the desktop Note that a new image Armbian 5.60 may be released soon, if you want that earlier, you could run apt-get upgrade armbian-config followed by armbian-config and switch to the nightly build if things are still not working for you, you may want to fall back to the Xenial 3.4 image instead, as you have mentioned it seem to work well for you i won't be able to help much with the wifi dongle but in armbian-config i think there is something like install/upgrade firmware package. i found that the 'firmware package' distribute quite a number of blobs and some of it seem to be related to wifi chips. you could try that to see if it helps. and this is for the stretch image and i'm using the nightly builds
  9. i'd like to suggest to get a new micro sd card and start afresh, i.e. new install from image, then apt-get upgrade armbian-config followed by things like running armbian-config (for 'switch to nightly' and other upgrades etc). sometimes such 'hardware issues' could be due to power issues, or rather the lack thereof. some 'mobile phone chargers' couldn't really deliver the 2 amps which i think orange pi pc easily consumes. if you consider that usb supplies 5v on the rails and it is 2 amps that the sbc / soc draws, that is a whopping 10 watts of power. it means one would need to get a 'phone charger' that can supply well in excess of 10 watts to keep the sbc and the sd card happy and running. those high amp chargers are available these days and try to go for those better ones with reliable specs. in addition, the usb cable connecting between the power supply (phone charger) to the sbc matters as well, get a good 'thick' copper wired cable so that it'd supply the power and not fail
  10. don't worry @tkaiser zram *is fast*, very fast in fact, the experience running x-desktop on orange pi pc 1gb ram and even orange pi one 512k ram is quite a bit smoother with zram however, it isn't about zram's speed that's the only consideration, e.g. for the orange pi one 512k ram, running on only ram and zram may land one with a freeze up / stall when memory really runs out especially when running on x11 desktop with various apps. hence some swap on flash is *inevitable* to overcome the simply *lack of ram*. then there are other issues on the fringes, such as ssh failed to connect after some time https://forum.armbian.com/topic/6751-next-major-upgrade-v560/?do=findComment&comment=62409 https://forum.armbian.com/topic/6751-next-major-upgrade-v560/?do=findComment&comment=62484 that seemed to be alleviated by setting a vm.swapiness, less than 100 leaving some room for some idle processes to simply 'stay in memory'
  11. but of course the high end desktops these days runs delivers much higher staggering gflops compared to simple arm chips https://www.pugetsystems.com/labs/hpc/Skylake-X-7800X-vs-Coffee-Lake-8700K-for-compute-AVX512-vs-AVX2-Linpack-benchmark-1068/ nevertheless arm chips these days on SBC could easily rival those of early p3, p4 and amd64 single core cpus
  12. hi all, as documented here, i did some minor experiments with small heatsinks on an orange pi one sbc (allwinner H3) among the things i used a small matrix multiplication program which multiplies a 1000x1000 matrix single precision floating point matrix main.cpp the command to build is c++ -O2 -std=gnu++11 -pthread -o mat main.cpp then run ./mat the last documented results on an orange pi one H3 running at 1.2ghz is 2389.49Mflops ~ 2.39Gflops the sources attached is 'optimised', the means of optimization is unrolling of the innermost loop to take advantage of platforms that could do quad sp fp simultaneous execute i think those neon enabled platforms would be able to do that. the other optimization is that it spawn off 4 threads so that it could utilise 4 simultaneous threads for the matrix multiplication could try to run this and let us know what is the 'mflops' you get on your sbc? what is the sbc , the soc and the frequency it is running at? note that this is not necessarily the most optimised for your sbc / soc the parameters you could try to tune includes the THREADS_NUMBER for the number of concurrent threads in the source code in addition those who have more powerful soc could try to unroll the loops further, e.g. try to compile with additional options like -funroll-loops or even -funroll-all-loops you could also manually update the codes e.g. to double the set of manually unrolled codes in the loop so that it become 8 sets of computations instead of 4, but you would need to review the codes such as using MATRIX_SIZE/8; i+= 8 in in the loop if you unroll the loop into 8 sets of variables, you'd need to update the summation after the loop as well result.elements[row][col] = r1+r2+r3+r4; to add the other r variables that you unrolled into the original 'unoptimised' codes can be found in references in the original post. strictly speaking this is not really a good test of computational prowess unlike those of linpack etc. linpack actually solves a matrix, and this is purely a square matrix multiply. in addition, this does not explicitly use neon etc and those usage depends on the compiler optimization (i think gcc / g++ has a build in vectorizer, hence you may like to experiment with the options) but nevertheless seeing mflops, gflops is fun, mflops, gflops is also normally a function of the frequency the core executes at, hence you could try to overclock your soc to get more gflops
  13. wow it is so extremely hot https://www.aliexpress.com/item/7inch-TFT-LCD-Screen-for-Orange-Pi-H3-chip-Boards/32831758014.html i used one of those hdmi switch instead https://www.ebay.com/sch/i.html?_nkw=hdmi+switch&amp;_sacat=0 and as it goes the one i used doesn't work very well, often switching between the displays ended with blank screens in the end i did something simplier. connect to the SBC via ssh over ethernet, x-desktop & the apps are installed and i simply send them over to the 'main' pc via ssh -X sbc sending individual app windows over is much preferred over VNC etc as it is low bandwidth and it feels like working on a same pc
  14. my apologies to have detoured from the topic, but yup no hurry to 'rush' into 4.19, it isn't 'born' yet , for now i think there is still the job of moving to 5.60 and actually fix issues found in 5.60 back on topic. one of those things is a 'modularised' build and deploy. if we could imagine we have build environments : stable, next and dev a 'development environment change flow' may be pictured as simply the reverse dev, next, stable (production) the trouble with projects grown this large is there are x number of socs, y number of boards, and z sets of kernels with specific patches that is not in mainline (and to add to that applications issues e.g. firefox, chromium and their giant suit of plugins, video acceleration, open gl es etc) at any one time a fix done for x soc, y board on z kernel, that may well be tested ok, but the rest of x socs, y boards, z kernels may well be still WIP and things are continuously happening ideally we'd be able to deploy the fix for x soc, y board on a particular 'module' say into 'next' for more testing before committing the same fix to stable. it isn't easy at all to manage that let alone even with git. git branches etc tend to take things 'wholesale', hence during a merge those WIP things say from other socs / boards get applied during the merge as well. one of those thoughts is say even with development branches that perhaps it may be possible to split the branches into the distinct groups. e.g.by socs/boards/kernels (i'd think at least soc & kernel) and even an 'application' branch. i'm not too sure if doing something like this could help to ease efforts when it comes to merging the fixes. of course the other way is to think of the main armbian build repository as 'master', and the development and next in separate repositories so that changes to armbian build 'master' comes as pull requests. and in the development repository there could be several branches say for groups of soc / kernels so that they are rather distinct to ease merging efforts well just thinking aloud, i'm not sure if this solve anything at all and may instead simply add complexity
  15. i tried out this dt overlay using the updated dtc 1.4.7 from debian repository, on my orange pi pc (h3) armbian (5.59 upgraded to 5.60 nightly sunxi-next 4.14.70), this is an attempt to change the keycode returned by gpio keys which maps to BTN_0 to KEY_POWER /dts-v1/; /plugin/; / { fragment@0 { target-path = "/r_gpio_keys/sw4"; __overlay__ { linux,code = <116>; }; }; }; saved that in a file say button.dts dtc -I dts -O dtb -o button.dtbo button.dts (as root) mkdir /sys/kernel/config/device-tree/overlays/button (as root) cat button.dtbo > /sys/kernel/config/device-tree/overlays/button/dtbo i've verified that it actually works, the overlay gets applied
  16. i think @Igor is preparing the release of 5.60 images, known issues found here could be resolved after that e.g. for users to switch to 'nightly' to get the incremental updates
  17. on kernel sunxi-next 4.14.70 (armbian 5.59 upgraded to 5.60 in nighly builds) orange pi pc i'm trying to setup the power tactile button to send a 'key' as input. i.e. using acpid to shutdown i did an $ ls /dev/input/by-path platform-1ee0000.hdmi-event platform-1f02000.ir-event the gpio key is absent, hence regardless of the dt overlays i apply, i don't receive any keys the things i checked are /boot/dtb/sun8i-h3-orangepi-pc.dtb decompiled (dtc -I dtb -O dts /boot/dtb/sun8i-h3-orangepi-pc.dgb ) the above looks ok however in /boot/config-4.14.70-sunxi # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADC is not set ... # CONFIG_KEYBOARD_GPIO is not set # CONFIG_KEYBOARD_GPIO_POLLED is not set i think CONFIG_KEYBOARD_GPIO needs to be configured as at least 'm' (module) or 'y' yes without it gpio keys inputs won't appear in /dev/input/by-path as the input driver is missing one main use of that button is by (orange pi *) users who wanted to use the 'power' button to shutdown the os via acpid but it could be useful in other situations as well
  18. @Moklev i'd suggest monitoring and tracking down the root cause of the ssh woes, one of those ways is to connect via a serial console when ssh fails https://forum.armbian.com/topic/8237-serial-console-access-via-usb-uartgadget-mode-on-linuxwindowsosx/ try to connect a cable via the micro usb OTG port to see if you get a linux console presented. if that works when ssh fails you could then 'get into' the board and do some checks like a armbianmonitor -u (if network fails you may need to run armbian monitor -U and saving the logs to a file) among the things check /sbin/sysctl -a |grep vm.swappiness vm.swappiness = 100 check in /etc/sysctl.conf if it is defined there you may like to reduce that value to 50 (or even for tests 0) to see if it made a difference there could also be other ways like hacking up a script to say ping the router every 5 minutes and if ping fails to capture a log like armbianmonitor -U > logfile ------ on a side note, i'd think 5.60 is still a useful 'milestone' to have
  19. i'm not too sure if the comments are still relevant for sunxi-dev kernel 4.18.8 but as i recently tested out armbian 5.59 transiting to 5.60, some of my findings with sunxi-dev kernel 4.18.8 are echoed here and here however, it do looks like linux kernel 4.19 release is rather close, it is already at 4.19rc4 https://www.kernel.org/ the commits on the main kernel tree is just as relentless https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ perhaps we'd do sunxi-dev 4.19 when it is out of rc rather than 4.18.8? and we'd perhaps leave 5.60 on 4.14.70 kernel? this is working very well on orange pi pc thanks for all that effort @Igor et.al but i think it is a little early to hold out too much hope on 4.19, i think the various late development fixes in 4.18.y linux-sunxi by the kernel team 'out there' would be in 4.19 that is a good thing as more mainline support would be built in. however, many of that broken in 4.18.8 may remain broken in 4.19 e.g. the sunxi64-dev
  20. thanks ! for now as the dtc which i used is apparently from the kernel source tree and distributed in debian / upstream from armbian, i'd make do and try that out first. it is rather likely that at some future 'upgrades' / releases of debian, this new version may be distributed instead. i'm not too sure what are the differences but in Pantelis Antoniou git, master branch seemed more updated than even dt-overlays5, but i've checked out (cloned) both branches in case there are some differences which is needed
  21. it seem the hdmi sound issue is related to this patch https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-add-HDMI-sound-nodes-DT.patch the main thing is the status = 'disabled' entries, i'm not too sure if there are other related kernel configs which may matter unfortunately i tried decompiling the dtb in /boot/dtb/sun8i-h3-orangepi-pc.dtb changing them to status = "okay" in my copy and replacing the dtb but thus far i did not manage to find the additional hdmi sound device after reboot. hence, this is not conclusive. it seemed there is also a mixer1 section that is missing in the decompiled dts
  22. i found a more recent dtc compiler which might be shipped in a 'future' release of debian (it isn't in nightly) that has the dynamic overlay and symbol substitution features it is actually a more recent version of dtc bundled with the linux kernel. Some how that recent version didn't get bundled with the recent kernels which uses those features
  23. there is this particular version of dtc by Pantelis Antoniou https://github.com/pantoniou/dtc which allows dynamic overlays and use of symbols instead of numeric addresses as references https://events.static.linuxfound.org/sites/events/files/slides/dynamic-dt-elce14.pdf after doing a bit of research i found that the more recent version of device-tree-compiler shipped with the kernel and armbian has built-in the dynamic overlays as well https://git.kernel.org/pub/scm/utils/dtc/dtc.git however, i found out that even with the nightly builds the current dtc version 1.4.2 isn't as recent as the updated version that could be found in debian repository http://httpredir.debian.org/debian/pool/main/d/device-tree-compiler/ i tried various commands apt-get etc but did not succeed in downloading the latest release what i did is to download that manually $ wget http://httpredir.debian.org/debian//pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_armhf.deb $ dpkg --install device-tree-compiler_1.4.7-3_armhf.deb this seem to work ok so far it might be shipped in a 'future' release / update of debian (it isn't in nightly) that has the dynamic overlay and symbol substitution features it is actually a more recent version of dtc bundled with the linux kernel. Some how that recent version didn't get bundled with the recent kernels which uses those features However, you could have that earlier by downloading it and installing the new version
  24. if i read this message https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/src/arm/sun8i-h3.dtsi?id=1dd2785450c025d11523a6108921355ce1524f01 it would not be correct to mark 4.18.8 as having no DVFS, but that this is WIP. Hence, we may anticipate further updates to this such as adding the 'missing' frequency bands. in this sense 4.18.8 use a 'safe' range of operating points between 648mhz and 1ghz (but not beyond) (for now). Orange pi one may run at lower temperatures, and some users may like that as they may be able to do away with the hassle of adding a heat sink. But users used to the performance orange pi pc, pi one etc would too soon discover that the higher frequencies of 1.2 ghz isn't used giving a minor loss of performance. Hdmi sound Hdmi sound is 'missing' in 4.18.8 but it is there in 4.14.70. I've not figured this out yet, it would be good if someone help to find out what cause it to be 'lost' and perhaps document it in a post here. e.g. is the problem in the dts for the boards? after it is 'discovered' i think patches could even be submitted to upstream in mainline (i.e. the kernel dts sources itself). But if anyone use the 4.18.8 kernel and wants the hdmi audio, they could then apply a patch e.g. against the dts source, recompile it and replace the dtb in /boot/dtb I've marked hdmi as 'yes' for orangepipc in 4.18.8 as basically video works, but I'd think some users would consider it a defect and wants hdmi audio added back
  25. i'm not too sure if this is relevant, in nightly builds in the recent armbian update 5.59.180919 on orange pi pc switching from the next-sunxi kernel (4.14.70) to dev-sunxi kernel (4.8.18) results in the following symptoms: dvfs: in 4.18.8 cpu seem to run only between 2 frequencies 648mhz, 1ghz while in 4.14.70 it is able to run in a range of frequencies 480khz to 1.29ghz i did a check between the dtb files (decompiling it using dtc -I dtb -O dts /boot/dtb/sun8i-h3-orangepi-pc.dtb) it turns out 4.18.8 do not have the operating point definitions that is there in 4.14.70 however, the dtb in 4.18.8 has some new definitions for csi (this may be good news for those wanting to try out the camera in the mainline kernel) various other definitions also varies between 4.14.70 vs 4.18.8 edit: found one of the answers: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/src/arm/sun8i-h3.dtsi?id=1dd2785450c025d11523a6108921355ce1524f01 hdmi-audio: in 4.18.8, i couldn't select hdmi-audio in pulseaudio volume control (on x11 desktop) while in 4.14.70 this is possible and i'm able to play a video with sound via hdmi audio i've not yet figured out the root cause of the 'missing' hdmi audio issue. my guess is 4.14.70 could be considered stable and 4.18.8 still considered development/experimental armbianmonitor -u for 4.14.70 https://pastebin.com/3NLDHaFs 4.18.8 https://pastebin.com/BXpx5qXh
  • Create New...