Re: [PATCH 1/2] panic: ratelimit panic messages

[Andrew Morton <akpm@linux-foundation.org>]

On Tue,  4 Jan 2011 22:38:30 -0500
Don Zickus <dzickus@redhat.com> wrote:

> Sometimes when things go bad, so much spew is coming on the console it is hard
> to figure out what happened.  This patch allows you to ratelimit the panic
> messages with the intent that the first panic message will provide the info
> we need to figure out what happened.
> 
> Adds new kernel param 'panic_ratelimit=on/<integer in seconds>'
> 

Terminological whinge: panic() is a specific kernel API which ends up
doing a sort-of-oops thing.  So the graph is

	panic		-> oops
	other-things	-> oops

Your patch doesn't affect only panics - it also affects oops, BUG(),
etc.  So I'd suggest that this patch should do s/panic/oops/g.

> ---
>  Documentation/kernel-parameters.txt |    6 ++++++
>  kernel/panic.c                      |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 316c723..1416964 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1807,6 +1807,12 @@ and is between 256 and 4096 characters. It is defined in the file
>  	panic=		[KNL] Kernel behaviour on panic
>  			Format: <timeout>
>  
> +	panic_ratelimit=	[KNL] ratelimit the panic messages
> +			Useful for slowing down multiple panics to capture
> +			the first one before it scrolls off the screen
> +			Format: "on" or some integer in seconds
> +			"on" defaults to 10 minutes
> +

We keep on hacking away at this and things never seem to get much
better.  It's still the case that a large number of our oops reports
are damaged because the important parts of the oops trace scrolled off
the screen.

I therefore propose

	oops_lines_delay=N,M

which will cause the kernel to pause for M milliseconds after emitting
N lines of oops output.  Bonus marks for handling linewrap!

Start the line counter at oops_begin() or thereabouts and then do the
delay after N lines have been emitted.  I guess that counter should
_not_ be invalidated in oops_end(): if the oops generates 12 lines and
then another 100 lines of random printk crap are printed, we still want
to put a pause after the 13th line of that random crap, so we can view
the oops.

The oops_lines_delay implemetnation should count lines from all CPUs
and should block all CPUs during the delay.

I think this would solve the problem which you're seeing, as well as
the much larger my-oops-scrolled-off problem?