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

[Jason Wessel]

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.

The API has only ever been used for one consumer of a crash and we
certainly don't want to resume the system.  I imagine we can just have
yet another modeset pre-saved that we can toggle.

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.

We had a prototype of something like atomic KMS for non KMS devices
but it was less than stable and not useful to kdb and has been
mothballed since 2009.

> 
>> Certainly I have had developers run kdb to dump a thread list and
>> other information in similar sorts of hard to debug scenarios where
>> there was no kdump, and send me jpegs.  Is the interface somewhat
>> generic and atomic?  It would be nice to be able to dump a pile of
>> data that you care about and snap a picture and have it show up on my
>> desktop or customer site -> support etc...
> 
> 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...

Cheers,
Jason.

...I can only imagine sometime down the road an embbedded jumbo-tron
crashing and displaying the QR code to a substantial audience (hope
someone with a phone takes a pic!)...