# Ker.4.4.16 AMD - Memory allocation failures and kernel panic

## x.para

Hi all,

on my android compiling machine I have systematic Memory allocation failures followed by kernel panic. This is always happening after some random time(30 mins, 1 hour, etc.).

Usually scenario is, that build fails due to make: fork: Cannot allocate memory

```

make: fork: Cannot allocate memory

make: *** Deleting file '/mnt/linuxdata/android/system/out/target/product/bullhead/obj/STATIC_LIBRARIES/libotafault_intermediates/libotafault.a'

make: fork: Cannot allocate memory

make: build/core/binary.mk:986: fork: Cannot allocate memory

make: fork: Cannot allocate memory

make: fork: Cannot allocate memory

make: *** Deleting file '/mnt/linuxdata/android/system/out/target/product/bullhead/obj_arm/SHARED_LIBRARIES/libaudioflinger_intermediates/AudioMixer.o'

make: fork: Cannot allocate memory

make: build/core/binary.mk:986: fork: Cannot allocate memory

make: fork: Cannot allocate memory

host Executable: imgdiff (/mnt/linuxdata/android/system/out/host/linux-x86/obj/EXECUTABLES/imgdiff_intermediates/imgdiff)

host Executable: bsdiff (/mnt/linuxdata/android/system/out/host/linux-x86/obj/EXECUTABLES/bsdiff_intermediates/bsdiff)

make: fork: Cannot allocate memory

make: fork: Cannot allocate memory

make: build/core/Makefile:623: fork: Cannot allocate memory

make: fork: Cannot allocate memory

make: *** Waiting for unfinished jobs....

make: Leaving directory '/mnt/linuxdata/android/system'

#### make failed to build some targets (55:53 (mm:ss)) ####

```

and then later few minutes later kernel crashes on Out of memory with following print out: https://drive.google.com/open?id=0BzcDsMBHQGzzZlBVSTdKRmhjRVk or similar https://drive.google.com/open?id=0BzcDsMBHQGzzRmdDNmpxRzFpNnM

I have 8GB RAM and rather worried, that my kernel is not properly configured in .config as I tried several kernels and all behaves same way. 

FREE shows 8GB RAM is installed.

anyone can advise what to focus on, in order to get this solved?

----------

## NeddySeagoon

x.para,

At face value, something is trying to use all your memory and the Out of Memory Manager cannot find any processes to kill, so the kernel is unable to allocate RAM for itself.

Do you have any swap space?

It may not help, since it can only be used for dynamically allocated RAM but if the underlying issue is a memory leak, you will be able to watch swap filling up before the crash.

You may even be able to spot the runaway process in top.

If its a leak, this won't stop it.  If something its allocating lots of RAM, it may help, providing at least a part of the allocation is swappable.

----------

## x.para

Thanks for response, yes I have SWAP. This is free output:

```

@stable ~ $ free

              total        used        free      shared  buff/cache   available

Mem:        8050120      100896     2984776       65076     4964448     3114740

Swap:       2046972           0     2046972

```

I am unable to see if swap is getting high right after the crash, so perhaps I can do 1second memory dump to see how memory is utilised before crash.

is there any setting in kernel that i could possibly miss, that would contribute to such behaviour?

----------

## NeddySeagoon

x.para,

You can watch top before and up to the crash.

Your free looks quite normal.  That's as expected as your system was operating normally at that time.

```
top - 12:45:10 up  2:19,  1 user,  load average: 0.00, 0.04, 0.05

Tasks: 241 total,   1 running, 240 sleeping,   0 stopped,   0 zombie

%Cpu(s):  0.5 us,  0.2 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

KiB Mem : 16408940 total, 15025640 free,   807620 used,   575680 buff/cache

KiB Swap:  2088432 total,  2088432 free,        0 used. 15296552 avail Mem 
```

watch the last two lines there.

The process list below that header may tell the problem process.

----------

## x.para

OK, so I think I have captured the problem. The crash happened many times even with idle machine on ng-syslog process,  that was heavy stormed by ACPI errors, warnings etc. even dmesg could not finish listing in 1 minute. So this is not related to load during the boot, but the system. 

However no time now for additional debugging now and sad to say very disappointed with today's portage consistency - even with stable branch, so this was kind of final straw for now. I builded different environment on the HW for now.

----------

## NeddySeagoon

x.para,

That sounds like a hardware problem.  

It will be interesting to see how the new  environment on the HW works.

----------

## x.para

OK, so I am on Debian Jessie to test if the problem was HW or SW and it looks system is totally stable - no ACPI errors, no issues with android builds. So it looks it was SW related. Perhaps I stay for a while on DEB to see if is stable and will consider come back to Gentoo later.

Thanks for help NeddySeagoon.

----------

