lkml.org 
[lkml]   [2006]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateFri, 6 Jan 2006 17:48:11 -0500
FromDave Jones <>
SubjectRe: oops pauser.
On Fri, Jan 06, 2006 at 04:22:03PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > The one case this doesn't catch is the problem of oopses whilst
> > > > in X. Previously a non-fatal oops would stall X momentarily,
> > > > and then things continue. Now those cases will lock up completely
> > > > for two minutes.
> > >
> > > The console has awareness of graphic/text mode at all times and knows
> > > what is going on. Why not use that information if you must go this way ?
> >
> > If we've just oopsed, the console may have no awareness of what day it is,
> > yet alone anything about video modes. I'm not entirely sure what you're
> > suggesting, but it gives me the creeps. Are you talking about switching
> > away from X back to a tty when we oops?
>
> No.
>
> But you _know_ if user is running X or not -- notice that kernel does
> not attempt to printk() when X is running, because that could lock up
> the box.
>
> If user is running X, you don't need the delay.
>
> if (CON_IS_VISIBLE(vc) && vc->vc_mode == KD_TEXT) {
> delay(10sec)
> }

From this context though, we don't have a 'vc' to reference,
so we'll need to find out from the console layer somehow, which
is the current vc.

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-06 23:50    [from the cache]
©2003-2010