ag123

  • Content Count

    92
  • Joined

  • Last visited

About ag123

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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
  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 ent
  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 withou
  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 fea
  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 'phon
  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 c
  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 loo
  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&_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
  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
  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 >