Jump to content

Regis Michel LeClerc

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by Regis Michel LeClerc

  1. Ok, brilliant... So, just to summarise, if I want my Orange Pi PC2 to use zRam instead of using a static 8GB off of my SDCard and compile the Monero thing (an operation that seems to require about 4GB anyway), how do I configure that, from start to end?
  2. Hi, Well, I'm not sure if it's a bug or what (when gcc crashes, it says to report it as a bug), but I was trying to compile Monero on an Orange Pi PC2 (yeah, pointless, I know, but just for the PoC) and the memory (and lack of swap) came up. Here's my config: root@orangepipc2:~/monero# uname -a Linux orangepipc2 4.14.7-sunxi64 #38 SMP Mon Dec 18 00:49:34 CET 2017 aarch64 aarch64 aarch64 GNU/Linux root@orangepipc2:~/monero# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepipc2 BOARD_NAME="Orange Pi PC2" BOARDFAMILY=sun50iw2 VERSION=5.37.171218 LINUXFAMILY=sunxi64 BRANCH=next ARCH=arm64 IMAGE_TYPE=nightly BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image Swapiness is configured as follows (looks good to me): root@orangepipc2:~/monero# sysctl -A 2>&1 | grep swap vm.swappiness = 60 and my zram is configured as follows: root@orangepipc2:~/monero# swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 124.3M 124.2M 5 /dev/zram1 partition 124.3M 124.2M 5 /dev/zram2 partition 124.3M 124.2M 5 /dev/zram3 partition 124.3M 124.2M 5 Ready to compile!... Huh? No. Running make (even "make -j1"!), the thing froze every time and took ages before I could ssh again (I'm not fond of unplugging it and the power-off button seems software-controlled, just like the LEDs, not a NMI, just as frozen as the OPiPC2 itself). It's so frozen that there's "no route to host" when I try to ssh or ping it (I keep it headless, there's nothing plugged on the USBs). The nohup.out shows that, within seconds, the situation comes to a point where cc1 is killed. Pretty ungood, isn't it? Initially, I thought it was CPU over-usage, but htop showed me it actually was the memory getting completely filled, and then the swap (but is it swap or zram in that case? there's no swap configured...). So, yeah, I know, it's not clean to configure swap on a SDCard, but: fallocate /var/swap.file --length 8GB ; chmod 0600 /var/swap.file ; mkswap /var/swap.file ; swapon /var/swap.file ; nohup make -j3 & Initially, I tried just 1GB, bringing total swap to 1.42GB, but htop showed it was eaten up in a matter of a couple of minutes, so I went directly to 8GB. At the moment, load average is at 4.17, swap is 2.15G of 7.94G (well beyond anything I could get without configuring a swap). It's not very reactive (to say the least), but it's working. So, unless there's a way to tell make/cmake//gcc to do otherwise, or a "cleaner" way to get the same result, adding a big swap on the SDCard was the only way to get things done... Slowly, wrongly, but done. Cheers, Regis
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines