On Tue, 2016-07-26 at 14:00 -0700, Andy Lutomirski wrote:
> 
> >> But doing this really nicely does tie in to the async printk
> >> discussion for a different reason.  I think that we should always
> >> initialize the obvious "early" consoles that can be cleanly enumerated
> >> early (e.g. EFI).  What we shouldn't do by default is *display*
> >> anything to them unless we crash, because the distro people want a
> >> clean boot to look pretty.  ISTM the condition for flushing the async
> >> printk buffers could be the same as the condition for actually writing
> >> to pre-VT consoles.
> >
> > Me no like.
> >
> > That makes even *less* sense for early boot than it does during later
> > runtime. Because even *more* of the 'we crash' scenarios during early
> > boot are going to be uncontrolled "oh shit" happenings, not "oh dear,
> > it looks like we're going to crash so let's helpfully dump out all the
> > console messages before we do so".
> 
> I only meant in the cases where we're currently silent.  If we boot
> with "quiet" and we panic, couldn't we at least try to flush out the
> printk buffer onto the early console?  Currently we just sit there
> with a blank screen.  (I debugged a case exactly like that last week.)

Sure, *that* part makes some sense if we can work out the details.

One of the issues is that you can end up with out-of-order messages —
for example if you've already printed everything above KERN_CRIT as it
happened, and you then go back and re-print the *whole* logbuffer when
you realise you're going to panic. If you *haven't* actually printed
any lines yet then that's kind of OK, but are you really intending to
keep track of that and behave differently if you have?

And if you spew *everything* on panic to a limited output like the
bootx or VGA text-mode console, you might find that the KERN_DEBUG
messages obscure what actually happened, which would be visible if you
only printed KERN_NOTICE and above... so maybe the best option is just
to honour the loglevel on the command line, but to do it *early*.
Heuristics for 'dump the logbuffer when you panic' still aren't a
panacea.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation