Re: [PATCH] vt/console: try harder to print output when panicing

On Wed, 23 Jun 2010 13:05:47 -0700
Jesse Barnes [off-list ref] wrote:

On Wed, 23 Jun 2010 12:56:05 -0700
Andrew Morton [off-list ref] wrote:

quoted

On Wed, 23 Jun 2010 13:12:59 +1000
Dave Airlie [off-list ref] wrote:

quoted

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?)