Re: Panic on OOM

[David Rientjes <rientjes@google.com>]

On Tue, 14 Jun 2011, Chris Fowler wrote:

> > Using /proc/sys/vm/panic_on_oom also won't panic the machine if you
> > happen to use a cpuset or mempolicy.  You'll want to write '2' instead
> > if you want to panic in all possible oom conditions.
> > 
> > 
> 
> 2 did it.  Thank you.
> 
> perl -e 'my @mem = (); while(1) { push @mem, "XXXXXXXXXXXXXXXX"; }'
> 
> I lost connection and it came back after about 30s.  Reboot worked.
> 

That wasn't meant as a fix for the problem but rather just a suggestion 
based on how you're using the device.

It's just a coincidence that it worked that time, because 
/proc/sys/vm/panic_on_oom == 2 is the exact same as 
/proc/sys/vm/panic_on_oom == 1 with the .config you posted (since you 
don't have CONFIG_NUMA, constrained_alloc() always returns CONSTRAINT_NONE 
in the oom killer).

More supporting evidence is that in the initial report that you said you 
had seen the panic and "Rebooting in 10 seconds..." message, yet no 
reboot.  That indicates the oom killer is working fine in both conditions.

So it's definitely the reboot code that is causing an issue that either 
hangs or takes excessively long, and that only happens sporadically for 
your machine.  The only differences between this code between v2.6.33 and 
v2.6.38 is how reboots are handled for Dell Precision T7400, VersaLogic 
Menlow based, and Apple iMac9,1.