[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m14otga4xa.fsf@fess.ebiederm.org>
Date: Mon, 13 Jul 2009 10:06:25 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>
Cc: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
kexec-ml <kexec@...ts.infradead.org>,
lkml <linux-kernel@...r.kernel.org>,
Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.
"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp> writes:
> Hi,
>
> This patch is a new version by Seto-san's comment.
>
>
> Changelog since v1:
> * Remove the check code other than kexec_crash_image from kexec_should_crash()
> because a kexec cannot crash if there is no image.
>
>
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
>
> Now, a kdump on oops is enabled if a kernel parameter "oops=panic"
> is specified and 2nd-kernel is loaded. I think that a kdump should
> be enabled regardless of "oops=panic" if 2nd-kernel is loaded,
> because a system administrator loads 2nd-kernel for enabling a kdump.
The Documentation for sysrq-c certainly needs to be updated.
If I am doing development on a system I like oops's. All of the
information and nothing goes down. I can get at /proc/kcore etc.
In a setting where I can't be Johnny on the spot and look at
things a core dump is probably the best I can get. In that scenario
panic_on_oops sounds good.
As I read the current check it reads:
If we are going to panic and not oops || panic_on_oops
kexec_should_crash = true;
Which seems a very reasonable implementation of policy.
Eric
--
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