[lkml]   [2010]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] vt/console: try harder to print output when panicing
    On Wed, 23 Jun 2010 12:56:05 -0700
    Andrew Morton <> wrote:

    > On Wed, 23 Jun 2010 13:12:59 +1000
    > Dave Airlie <> 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. However if
    oops_in_progress is set (as it is whenever bust_spinlocks(1) is called,
    i.e. from panic() and oops_begin()) we'll try to print into the fbcon
    buffer. In the oops case this should still be safe since the buffer is
    pinned, at least in the KMS world.

    > Worse, there's also a risk that doing all this new work within the
    > oopsing context will screw the machine up, so the user will be
    > _deprived_ of an oops report which he otherwise would have been able to
    > get from the logs. This is particularly the case when it's the DRI
    > stuff which oopsed, which is not exactly an uncommon occurrence lately ;)
    > Oh well, the best way to tell is to ship-it-and-see.

    To avoid the oops part (which as I said should still be safe) we could
    add a new panic_in_progress flag, that would make sure things were no
    worse than they are currently.

    Jesse Barnes, Intel Open Source Technology Center

     \ /
      Last update: 2010-06-23 22:09    [W:0.023 / U:130.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site