From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Airlie <airlied@gmail.com>,
linux-fbdev@vger.kernel.org, dri-devel@lists.sf.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vt/console: try harder to print output when panicing
Date: Wed, 23 Jun 2010 20:40:24 +0000 [thread overview]
Message-ID: <20100623134024.713e0714@virtuousgeek.org> (raw)
In-Reply-To: <20100623133637.fbb318e2.akpm@linux-foundation.org>
On Wed, 23 Jun 2010 13:36:37 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 23 Jun 2010 13:05:47 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > On Wed, 23 Jun 2010 12:56:05 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Wed, 23 Jun 2010 13:12:59 +1000
> > > Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > > Jesse's initial patch commit said:
> > > >
> > > > "At panic time (i.e. when oops_in_progress is set) we should try a bit
> > > > harder to update the screen and make sure output gets to the VT, since
> > > > some drivers are capable of flipping back to it.
> > > >
> > > > So make sure we try to unblank and update the display if called from a
> > > > panic context."
> > > >
> > > > I've enhanced this to add a flag to the vc that console layer can set
> > > > to indicate they want this behaviour to occur. This also adds support
> > > > to fbcon for that flag and adds an fb flag for drivers to indicate
> > > > they want to use the support. It enables this for KMS drivers.
> > >
> > > Interesting. Getting real oops traces from machines running X will
> > > make Rusty happy, and that's what we're all here for.
> > >
> > > How well does this all work? How reliable is it? What's the success rate?
> > >
> > >
> > >
> > > What's the downside here? After all, not all oopses are catastrophic -
> > > sometimes the machine will go blurt and keep running so the user can
> > > take a look in the logs then perform an orderly reboot, etc. As I
> > > understand it, those non-catastrophic oopses will now flip the machine
> > > from X and into the vt display, yes? Can the user get it back to X
> > > mode?
> >
> > No, we'll only flip from the panic notifier chain.
>
> So we still don't get to see the output from BUGs and random oopses? I
> don't think panics are all that common.
No, BUG() ends up in panic iirc by doing an bad pointer ref which
should fault and panic. Random oopses won't show up though (but they're
not supposed to be fatal and can be seen in the log).
> So am I correct in believing that if a user is getting invisible-oopses
> then he can set /proc/sys/kernel/panic_on_oops, and then the oops
> should be visible?
Yep.
> (Shouldn't all this stuff be explained in the changlog?)
Maybe? Linux oops/panic handling is pretty ad-hoc, a separate document
would probably be best.
--
Jesse Barnes, Intel Open Source Technology Center
prev parent reply other threads:[~2010-06-23 20:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 3:12 [PATCH] vt/console: try harder to print output when panicing Dave Airlie
2010-06-23 15:43 ` Jesse Barnes
2010-06-23 15:57 ` James Simmons
2010-06-23 19:56 ` Andrew Morton
2010-06-23 20:05 ` Jesse Barnes
2010-06-23 20:36 ` Andrew Morton
2010-06-23 20:40 ` Jesse Barnes [this message]
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=20100623134024.713e0714@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dri-devel@lists.sf.net \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).