public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	fweisbec@gmail.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] panic:  ratelimit panic messages
Date: Wed, 5 Jan 2011 21:05:12 -0500	[thread overview]
Message-ID: <20110106020512.GJ2317@redhat.com> (raw)
In-Reply-To: <20110105145128.3b635ae7.akpm@linux-foundation.org>

On Wed, Jan 05, 2011 at 02:51:28PM -0800, Andrew Morton wrote:
> 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.

Ok.  Sorry about that.

<snip>
> 
> 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?

Ok.  Forgive me for being thick.  I seem to be lost in the lower layer of
the oops code for some reason.  I understand your idea and am willing to
take a crack at implementing it, I just can't figure out what function to
stick it in.  I grep'd for oops_begin() and it seemed to be an x86-only
thing.  Is there a more generic place to put this stuff?

Cheers,
Don

> 

  reply	other threads:[~2011-01-06  2:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05  3:38 [PATCH 0/2] touch_nmi_watchdog semantic changes Don Zickus
2011-01-05  3:38 ` [PATCH 1/2] panic: ratelimit panic messages Don Zickus
2011-01-05 13:21   ` Ingo Molnar
2011-01-05 14:00     ` Don Zickus
2011-01-05 22:51   ` Andrew Morton
2011-01-06  2:05     ` Don Zickus [this message]
2011-01-06  2:16       ` Andrew Morton
2011-01-15  8:29     ` Dave Young
2011-01-15 11:03       ` Dave Young
2011-01-05  3:38 ` [PATCH 2/2] watchdog: touch_nmi_watchdog should only touch local cpu not every one Don Zickus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110106020512.GJ2317@redhat.com \
    --to=dzickus@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox