[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMP44s19U3wJ5PdvqeoE=LX9R9dyV0t5P-1f9RN1hvn-yrNW1Q@mail.gmail.com>
Date: Wed, 27 Nov 2013 00:13:57 -0600
From: Felipe Contreras <felipe.contreras@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Jason Baron <jbaron@...mai.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>, ralf@...ux-mips.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] panic: Make panic_timeout configurable
On Tue, Nov 19, 2013 at 1:15 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
>
>> On Mon, 18 Nov 2013 21:04:36 +0000 (GMT) Jason Baron <jbaron@...mai.com> wrote:
>>
>> > The panic_timeout value can be set via the command line option 'panic=x', or via
>> > /proc/sys/kernel/panic, however that is not sufficient when the panic occurs
>> > before we are able to set up these values. Thus, add a CONFIG_PANIC_TIMEOUT
>> > so that we can set the desired value from the .config.
>> >
>> > The default panic_timeout value continues to be 0 - wait forever, except for
>> > powerpc and mips, which have been defaulted to 180 and 5 respectively. This
>> > is in keeping with the fact that these arches already set panic_timeout in
>> > their arch init code. However, I found three exceptions- two in mips and one in
>> > powerpc where the settings didn't match these default values. In those cases, I
>> > left the arch code so it continues to override, in case the user has not changed
>> > from the default. It would nice if these arches had one default value, or if we
>> > could determine the correct setting at compile-time.
>>
>> Felipe is proposing a simpler patch ("panic: setup panic_timeout
>> early") which switches to early_param(). Is that sufficient for the
>> (undescribed!) failure which you are presumably observing?
>
> Also note that that patch is still incomplete: if panic_timeout is
> switched to early_param() then closely related functionality such as
> pause_on_oops should be moved early as well...
If that was the case, then whomever made the "oops" param generic sent
an incomplete patch because it's also early_param, and it's
interesting why you didn't have that problem with that patch, but you
do with this one.
--
Felipe Contreras
--
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