[Ksummit-discuss] [TECH TOPIC] asynchronous printk

Sergey Senozhatsky sergey.senozhatsky.work at gmail.com
Tue Jul 19 08:23:20 UTC 2016


On (07/19/16 10:02), 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?

ah, ok. so mostly for the reasons outside of printk/panic code.
hard lockup, case. hm, I think nmi_panic() is still going to
call panic() at some point. so we have chances to flush log_buf
messages.

power down or h/w failure, however, can't be fixed up neither
by sync nor by async printk. well, we can't help here.


the thing that really can stop us from flushing the messages
is the fact that console driver may be in some unknown state.
for example, have some internal locks owned by non-panic CPU,
which we IPI_STOP-ed before console_flush_on_panic(). console
drivers are normally unaware of the fact that the system is in
panic now. so some sort of console->write_on_panic(), or
console->reset() would probably be helpful, but that's a bit
different topic.

	-ss


More information about the Ksummit-discuss mailing list