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)
}
or something like that should do the trick.
Pavel
--
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
