Messages in this thread | | | Date | Tue, 14 Jun 2011 19:32:18 -0700 (PDT) | From | David Rientjes <> | Subject | Re: Panic on OOM |
| |
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.
| |