Messages in this thread |  | | | Date | Fri, 6 Jan 2006 17:48:11 -0500 | | From | Dave Jones <> | | Subject | Re: 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/
|  |