[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F1C966DF1@ORSMSX108.amr.corp.intel.com>
Date: Mon, 10 Dec 2012 18:19:15 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Don Zickus <dzickus@...hat.com>,
Seiji Aguchi <seiji.aguchi@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"cbouatmailru@...il.com" <cbouatmailru@...il.com>,
"ccross@...roid.com" <ccross@...roid.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>,
Satoru Moriya <satoru.moriya@....com>
Subject: RE: [RFC][PATCH] pstore: Skip spinlock when just one cpu is online
> But you are assuming that kmsg_dump is perfect and it isn't, in which case
> by putting kmsg_dump in the kdump path, you actually may be blocking kdump
> from working.
I think the concern is that kdump isn't perfect, so sometimes we don't get a good dump
from it. In those cases it would have been nice to have a pstore log of the original
problem.
But ... I don't see an answer to this problem. Adding more code just increases the
number of possible places we can fail (especially as we are executing in a state
where we know that things are all messed up ... the first kernel panic'd because
something bad happened that we didn't know how to fix).
A boot argument might help - so we can force use of pstore in cases where
kdump is failing (or prevent use of pstore in cases where it seem to be preventing
us getting to kdump ... I don't have a preference). BUT this would only be useful
if we had a repeatable problem so that we could switch to the other mode ... and
it seems likely that the kinds of problems that cause pstore or kdump to fail would
be weird cases that are not very repeatable :-(
-Tony
--
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