[Ksummit-2012-discuss] [ATTEND] kernel core dump and "dying breath"

[Matthew Garrett]

On Fri, Jun 22, 2012 at 03:00:06PM -0500, Jason Wessel wrote:
> On 06/22/2012 02:39 PM, Matthew Garrett wrote:
> > On Fri, Jun 22, 2012 at 02:34:38PM -0500, Jason Wessel wrote:
> > 
> >> On the QR Code front, I am curious what the interface to this is?
> >> Atomic KMS and what about goofy cards like Nvidia where you don't
> >> always get KMS?
> > 
> > KMS already has atomic modeswitch support for showing panics. We'd just 
> > need to ensure that there's an unaccelerated path for dumping contents 
> > directly to the framebuffer. If you don't have KMS then you don't get to 
> > play with modern useful functionality.
> 
> Having worked on the atomic KMS support with Jessie Barnes I am very
> familiar with the API, we would probably need to add something if we
> wanted to be able to perform a secondary switch while still atomic.
> The example being Crash -> kdb -> find what you want and asking for
> the QR code to display.

That shouldn't require a secondary switch - we just need to be able to 
render into the same framebuffer.

> For the non-proprietary / unaccelerated path, it sure would be
> nice an atomic gfx API and in this case of the "kiss of death" it is
> ok if it is a one way trip to the ultimate reboot.  Today it is just a
> whole pile of major ugly which is why no one had attempted working on
> it yet.  :-) The last time I did look at this the best almost seemed
> like the kexec type approach where you just assume we are toast and
> init the HW back to VESA, the problem being it would have to have been
> preconfigured for that monitor LONG before you crashed.

There's no guarantee that you can perform a VESA modeset once you've 
touched the hardware directly. It might be safe for text mode, but 
really vendors need to just get their act together and support KMS. On 
x86 the only problematic chipsets you're likely to find are nvidia users 
insisting on the proprietary driver, or VIA.

> > I was only considering using it for panics - I guess you want to be able 
> > to expose more specific data as well as the backtrace?
> 
> Yes, sometimes you need the ftrace buffer, sometimes it is the thread
> list, or the fs locks or a hex dump of memory, which you later
> disassemble.  I was just looking for something nice to use where when
> I saw what I wanted I could get it in a picture, OR pre configure an
> arbitrary death script for the data I desire.  And thinking from the
> embedded angle, it isn't always desktops.  It is HDMI attached
> displays to some homegateway, tablets, small devices etc...

Yeah, that might be nice to have.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org