[Ksummit-discuss] [TECH TOPIC] asynchronous printk

David Woodhouse dwmw2 at infradead.org
Thu Jul 21 10:36:42 UTC 2016


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 at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160721/2a915a46/attachment.bin>


More information about the Ksummit-discuss mailing list