Moklev

Members
  • Content Count

    65
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by Moklev

  1. It's a problem, "armbianmonitor -u" is broken, all free service (pastebin, ghostbin, etc...) are limited to 512kB-1,5MB. Now is not possibile to upload all necessary data. SBC is crashed on 20.09 (boot at 13:05, crashed at 15:35*), on 21.09 (boot at 14.00 then crashed at 17.37*) and on 22.09 (boot at 13:35 then crashed at 23.12*). (*): timestamp of the last picture shooted and processed. Sunday (23.09) I've changed the vm.swappiness to 30 and the problem has been solved. Now I need the following directions to help you: - when to run the "free -m" command - how to send the log if armbianmonitor does not work - how long to run the indicated scripts I need at least 1 or 2 weeks to do everything...
  2. vm.swappiness=100 https://ghostbin.com/paste/vrt5t With vm.swappiness=30: system work fine With wm.swappiness=100: system work fine for a random time (3-12 h), then hang with ssh unreachable, yellow ethernet led fixed on, pihole/motioneye/rpi monitor web pages unreachables. Hardware: OrangePI Zero v1.4 - Sandisk uSD 16GB U1 A1 (checked, good healt) EXT4 - Toshiba USB Stick 32GB (checked, good healt) F2FS, USB PSU FriendlyARM 5V/3A (checked, good healt).
  3. First log (reduced because too large): Orange Pi Zero (vm.swappiness=30) https://ghostbin.com/paste/vxqdd
  4. Debian 9.5 AMD/Microserver (vm.swappiness=60) iostat.log root@tubserver:~# cat iostat.log Linux 4.17.0-0.bpo.3-amd64 (tubserver) 27/09/2018 _x86_64_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0,09 0,01 0,15 0,29 0,00 99,45 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 1,55 24,94 27,24 21613817 23605307 sdb 1,23 4,76 27,24 4122642 23605307 md3 0,22 0,77 0,13 669789 109496 md1 0,00 0,00 0,00 2304 0 md2 0,36 26,05 19,72 22569513 17083692 md0 1,55 2,89 7,29 2501781 6313004 sdc 0,18 1,12 1,80 973561 1560460 zram0 0,01 0,00 0,03 2660 29588 zram1 0,01 0,00 0,04 2904 38420 avg-cpu: %user %nice %system %iowait %steal %idle 0,10 0,00 0,15 0,73 0,00 99,02 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 2,81 0,05 68,93 28 41359 sdb 2,77 0,00 68,93 0 41359 md3 0,00 0,00 0,00 0 0 md1 0,00 0,00 0,00 0 0 md2 0,00 0,00 0,00 0 0 md0 4,50 0,05 68,74 28 41244 sdc 0,00 0,00 0,00 0 0 zram0 0,00 0,01 0,00 4 0 zram1 0,00 0,00 0,00 0 0 free.log root@tubserver:~# cat free.log gio 27 set 2018, 11.22.53, CEST total used free shared buff/cache available Mem: 1743 257 123 26 1362 1278 Swap: 2776 55 2721 gio 27 set 2018, 11.24.12, CEST total used free shared buff/cache available Mem: 1743 258 121 26 1363 1276 Swap: 2776 55 2721 gio 27 set 2018, 11.27.01, CEST total used free shared buff/cache available Mem: 1743 260 155 26 1327 1274 Swap: 2776 54 2722 gio 27 set 2018, 11.37.01, CEST total used free shared buff/cache available Mem: 1743 260 154 26 1328 1274 Swap: 2776 54 2722 Tomorrow for OPZ/Armbian data... both for vm.swappiness=30 and 100 (and armbianmonitor -u)
  5. After warm reboot... ~70-72°C it's a badly reported temperature, correct value -measured with a Fluke thermometer- is ~65°C on the SOC heatsink. It's normal, the scb works as a visual motion analizer (1 h264 hd stream) 24/7 since mid 2017. Yes, I've starting monitoring... They are not... totally different purpose or software stacks... and power outlet. Anyway now my OPZ works stable again with Armbian 5.60 (with vm.swappiness set to 30-60).
  6. @ag123 The good thing: reducing the value to 30 (vm.swappiness = 30) seems to solve the problem. Now I got ~22 h uptime without any hang... The bad one: an heavy zram usage on my AMD/Debian 9.5 microserver freeze the system (both gnome shell and ssh). :-| I think zram has some problems with Debian...
  7. Interesting... I'll change swap threshold to a more conservative value to 30 and I'll test it for 24/48h.
  8. Still stability issues on stable v5.60 (v5.59 upgraded to 5.60). I can not have an uptime over 3-12 hours (it is not reachable via ssh or webgui). SD and psu are OK. The system run stable on old v5.38 (january 2018) with same setup for weeks. Orange Pi Zero 512/v1.4 system log: http://ix.io/1ngD
  9. All right! Native zRAM implementation work very well in Armbian (next) v5.59 (tested on my Pi Zero and PC2). EDIT (problem with v5.60 and vm.swappiness = 100):
  10. My Orange Pi PC2 work fine with Stretch (mainline, 4.14.48) between 35 and 65 °C. I got only a minor (but annoying) problem: the board start overheating after a shutdown (sudo shutdown -h now) and reach >70 °C after few minutes. Is it a kernel problem? Or a hardware design fault?
  11. They have released the first version (07_2018) https://bootlin.com/blog/allwinner-vpu-main-goals-delivery/ https://linux-sunxi.org/Sunxi-Cedrus#2018.07_Releases
  12. https://forum.armbian.com/topic/7502-ov5640-on-mainline-kernel/
  13. Me too... with an old HP z400 Workstation (Xeon W3530, 12GB ECC DDR3 and a SSD Crucial MX300) build process is quite fast.
  14. Moklev

    NanoPI M4

    An extrusion process - compared to cnc machining - isn't more cheaper (economically and energetically)? Like new Asus case for Tinker Board: https://www.asus.com/Single-Board-Computer/Tinker-Fanless-Aluminum-Case/
  15. Yes... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
  16. Bootlin has released the new blobs (32&64 bit, X11/fbdev/Wayland, r6p2/r8p1). https://bootlin.com/blog/more-opengl-binaries-for-the-mali-support-on-allwinner-platforms-with-mainline-linux/ https://github.com/free-electrons/mali-blobs
  17. It looks like Yong Deng's patch for V3s CSI. +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2011-2018 Magewell Electronics Co., Ltd. (Nanjing) + * All rights reserved. + * Author: Yong Deng <yong.deng@magewell.com> + */ Here: https://www.spinics.net/lists/linux-media/msg130006.html http://linux-sunxi.org/Linux_mainlining_effort
  18. This sounds very interesting! But ... I can not find the interface driver (sun6i_csi). This is the Maxime Ripard's patch to mailine kernel or another one? For the testing: I've a Orange Pi PC2 H5 and a OV5647 NoIR CSI.
  19. (disclaimer) No itention to make a Frankendebian (https://wiki.debian.org/DontBreakDebian) but ubuntu package "zram-config" works perfectly. I tested it for two weeks in a: Orange PI Zero 512MB Armbian Stretch 5.40 4.14.18, Orange PI PC2 Armbian Stretch 5.40 4.14.18, AMD Sempron microserver Debian Stretch 9.4 4.9.0-6-amd64. A short tutorial: 1. Download zram-config package (it's a universal package, it does not matter the architecture in use) wget http://de.archive.ubuntu.com/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb 2. Install it sudo dpkg -i zram-config_0.5_all.deb 3. Remove the installer rm zram-config_0.5_all.deb 4. Check vm.swappiness cat /proc/sys/vm/swappiness (must be 60, default) 5. If not (i.e. "cat /proc/sys/vm/swappiness" return "1" ) change it to "60" sudo nano /etc/sysctl.conf and add "vm.swappiness=60" at the end of file ... and reboot 6. check zRAM service sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo 437,8M 5,2M 1,4M 1,9M 2 [SWAP] /dev/zram1 lzo 437,8M 5,2M 1,4M 1,9M 2 [SWAP] 7. (optional) change lzo compression to lz4 sudo nano /usr/bin/init-zram-swapping # initialize the devices for i in $(seq ${NRDEVICES}); do DEVNUMBER=$((i - 1)) echo $mem > /sys/block/zram${DEVNUMBER}/disksize mkswap /dev/zram${DEVNUMBER} swapon -p 5 /dev/zram${DEVNUMBER} done to... # initialize the devices for i in $(seq ${NRDEVICES}); do DEVNUMBER=$((i - 1)) echo lz4 > /sys/block/zram${DEVNUMBER}/comp_algorithm echo $mem > /sys/block/zram${DEVNUMBER}/disksize mkswap /dev/zram${DEVNUMBER} swapon -p 5 /dev/zram${DEVNUMBER} done 8. restart the service sudo systemctl restart zram-config.service 9. check new compression algorithm sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 437,8M 5,2M 1,4M 1,9M 2 [SWAP] /dev/zram1 lz4 437,8M 5,2M 1,4M 1,9M 2 [SWAP] 10. check the zRAM priority over file swap cat /proc/swaps zRAM devices must be at priority "5", swap file at "-1" or "-2" 11. finish :-)
  20. An Asus Tinkerboard (Mali-T764) or a Rock64 (Mali-450MP4)? With a quite good support: http://opensource.rock-chips.com/wiki_Status_Matrix Try to build r6 driver by Free Electrons: https://github.com/mripard/sunxi-mali Kernel module: git clone https://github.com/mripard/sunxi-mali.git cd sunxi-mali export CROSS_COMPILE=$TOOLCHAIN_PREFIX export KDIR=$KERNEL_BUILD_DIR export INSTALL_MOD_PATH=$TARGET_DIR ./build.sh -r r6p2 -b ./build.sh -r r6p2 -i ... and the userspace driver: git clone https://github.com/free-electrons/mali-blobs.git cd mali-blobs cp -a r6p2/fbdev/lib/lib_fb_dev/lib* $TARGET_DIR/usr/lib Pay attention: "In order to build the kernel module, you'll need a functional DRM driver. If you have that already, you'll need the options CONFIG_CMA and CONFIG_DMA_CMA enabled in your kernel configuration."
  21. Ops... :) Zero plus 2 is the H5 version? CPUFreq is in WIP stage also for the H5... all H boards have problem scaling down in idle with kernel 4.14.
  22. OPZ H2+ (v1.4) is a hot board. I got 68-72°C running pihole and motioneye, with passive heatsink and plastic case (without stability problems, for 1 year). With mainline kernel 4.14.yy frequency scaling isn't perfect... full cpufreq implementation is espected for 4.18.yy
  23. Have you tried to build it? git clone https://github.com/xbmc/xbmc.git git clone https://github.com/kodi-pvr/pvr.iptvsimple.git cd pvr.iptvsimple && mkdir build && cd build cmake -DADDONS_TO_BUILD=pvr.iptvsimple -DADDON_SRC_PREFIX=../.. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../../xbmc/addons -DPACKAGE_ZIP=1 ../../xbmc/cmake/addons make
  24. Same in 5.40 (Orange Pi Zero and Orange Pi PC2, Debian Stretch 9 server): armbian-config stuck changing locale from EN to IT (from en_US.UTF-8 to it_IT-UTF-8. You need to change manually by editing /etc/default/locale.
  25. @guidol http://linux-sunxi.org/Linux_mainlining_effort#Planned_for_4.18 CPUFreq for H2/H3/H5 on 4.18.yy