On Tue, Nov 19, 2013 at 1:15 AM, Ingo Molnar <mi...@kernel.org> wrote:
>
> * Andrew Morton <a...@linux-foundation.org> wrote:
>
>> On Mon, 18 Nov 2013 21:04:36 +0000 (GMT) Jason Baron <jba...@akamai.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to