You are not logged in.
Sorry I forgot to add that my system completely freezes and is unresponsive...no SSH either.
I am attempting to build Android code more specifically LineageOS.
I will start by saying I have not had problems doing this in the past.
I have tried using both make and ninja by using the enviroment variable USE_NINJA=(yes or no).
I have done memtest with a pass.
I have done the intel CPU check as described by some wiki I can't remember at the moment.
I only have 4GiB of ram but, I have created a 24GiB swap on my SSD that is set to 100 on swapiness (was having freezing issues).
I have an external hard drive over USB 3.0 (/dev/sdb1) mounted to the out directory (/home/ME/android/system/out) of my build.
Applicable information:
fdisk -l (my external isn't listed because I'm too lazy to reconnect it....but trust me it is mounted when I do my builds)
Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0371F390-E9B5-4D03-85AE-79CB66F6476ADevice Start End Sectors Size Type
/dev/sda1 2048 4196351 4194304 2G EFI System
/dev/sda2 4196352 46139391 41943040 20G Linux filesystem
/dev/sda3 46139392 96471039 50331648 24G Linux swap
/dev/sda4 96471040 113248255 16777216 8G Linux filesystem
/dev/sda5 113248256 250069646 136821391 65.2G Linux filesystem
space(bash alias for free -h && df -h)
total used free shared buff/cache available
Mem: 3.8G 1.0G 2.2G 134M 591M 2.4G
Swap: 23G 0B 23G
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 4.7M 1.9G 1% /dev/shm
tmpfs 1.9G 804K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda2 20G 3.9G 17G 20% /
tmpfs 1.9G 0 1.9G 0% /tmp
/dev/sda1 2.0G 101M 1.9G 5% /boot
/dev/sda4 8.0G 158M 7.9G 2% /var
/dev/sda5 66G 63G 3.1G 96% /home
tmpfs 386M 4.0K 386M 1% /run/user/1000
http://i.imgur.com/k6E2WUu.jpg
Anything else I should add?
-- mod edit: replaced img with url tags. See guidelines on image sizes. Trilby --
Last edited by dazemc (2017-06-17 16:55:19)
Offline
'/','/var','/home', and the external '/dev/sdb1' are formatted in xfs.
Ummm not an overheating problem....
Tested with a simple script to fill up memory and was able to get all the way up to 23GiB before freezing.
I'm not even getting close to 6GiB when actually building.
Last edited by dazemc (2017-06-17 09:34:18)
Offline
You're swapping and make is I/O prone anyway - since you didn't specify an issue: is there actually a real problem or is it "just slow"?
You could try another IO scheduler, build with less (one) jobs or swap to another disk.
Offline
You're swapping and make is I/O prone anyway - since you didn't specify an issue: is there actually a real problem or is it "just slow"?
You could try another IO scheduler, build with less (one) jobs or swap to another disk.
Sorry I was so caught up in trying to provide as much information as I could.
I definitely expect it to run slow. But, my system is completely freezing up and unresponsive.
I have journlctl set to be persistent and I have checked through those logs and have found nothing.
Offline
make -j 1
https://wiki.archlinux.org/index.php/Im … schedulers
If this is a swapping issue, responisveness can easily be measured in minutes, so try to break the process (ctrl+c, couple of times won't hurt ;-) and go for a cup of coffee to see whether the system comes back.
Also a swappiness of 100 says "swap as much as you can", iirc there was even a bug on a level of 100 (to cause freezes?) - i'm not sure whether that's actually what you want.
Offline
for most cases, even cases you expect to swap a lot, 60 swappiness (the default) is fine. swap should only get used when necessary. if anything, you should lower swappiness, to try to force some system files to swap instead of active files. if you're going 2TiB over your RAM, however, going below 60 isn't going to offer much assistance.
as mentioned above, try another scheduler. have a terminal with top/htop open to see where you're actually failing. consider using iotop as well.
Offline