On Wed, 23 Jun 2010 13:05:47 -0700 Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 23 Jun 2010 12:56:05 -0700 > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, 23 Jun 2010 13:12:59 +1000 > > Dave Airlie <airlied@xxxxxxxxx> 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. 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? (Shouldn't all this stuff be explained in the changlog?) -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
