On Monday, March 19, 2007 1:05 pm David Miller wrote:
quoted text
> From: Jesse Barnes <jesse.barnes@intel.com>
> Date: Mon, 19 Mar 2007 12:54:36 -0700
>
> > Kernel based modesetting should get us a lot of things:
>
> But for panics you're ignoring what Peter and I are saying.
>
> Mode setting is complex and it is not going to work exactly when you
> need the kernel crash message the most.
>
> After debugging the kernel for 10+ years I can tell you one thing,
> for a bad crash what's going to happen is you'll get the printk but
> that's about all that will work at that point, and the kernel is
> going to hang next.  Sometimes you won't get the whole panic message,
> just the beginning, even with the most simplistic printk
> implementation.
>
> You will not, I repeat, will not be able to mode switch or anything
> non-trivial like that when the kernel is in this state.
>
> Mode switching on panic, just say no. :-)

You must have missed this part:

"As for what happens at panic time, if the kernel knows how to modeset 
we can do whatever we want:  conservatively clear an appropriate 
scanout buffer and render our panic there, switch into a better mode to 
dump the panic if we think that's possible, or just hang without any 
output like we do today."

Where "an appropriate" might mean "currently active" which would give us 
what you and Peter are saying.  The point is, with the modesetting code 
in the kernel, we'll actually *have* all the information you outlined 
in your previous mail so we'll have a chance to dtrt when the panic 
occurs (which is to tell the user about it).

So don't worry, I'm not ignoring that point at all, doing much of 
anything after panic/oops is a crapshoot. :)

Jesse
-
unsubscribe notice
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/