On Tue, 2016-07-19 at 10:02 +0200, Hannes Reinecke wrote:
> > so why would the system die before we console_unlock()?
> > 
> Errm.
> Because it doesn't have any other chance?
> Like, hard lockup?
> Power down?
> Hardware dead?
> 
> Slightly puzzled,

Right. This was exactly the kind of hang I was chasing shortly before
last year's KS — an interrupt storm killing the box (because of a
tendency in network drivers to return IRQ_HANDLED and not really care
if we *had* done so, which ISTR arguing with DaveM about separately).

Sometimes you don't get a nice clean panic. Sometimes you just get a
lockup or a hard reset.

Which is also why it doesn't help much to try to use the level of an
individual printk to determine whether it should be synchronous or not.
In this case it was all KERN_DEBUG messages from the network driver,
which I was logging to the serial port so I could see what was
happening... but which weren't making it out the port before the
lockup.

A viable solution to fix this might be a 'synchronous' flag on the
console itself — so I could boot with 'console=ttyS0,synchronous' and
get a debuggable system again, Or maybe it would be simpler to have a
system-wide control which makes all consoles synchronous, if that's
easier. Either way, we do need the option, and we need it to apply to
*all* output, not just KERN_EMERG messages.

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