[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1106141908100.7025@chino.kir.corp.google.com>
Date: Tue, 14 Jun 2011 19:32:18 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Chris Fowler <cfowler@...dc.com>
cc: linux-kernel@...r.kernel.org
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists