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
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.