On Thu 2018-11-29 19:09:26, Tetsuo Handa wrote: > On 2018/11/28 22:29, David Laight wrote: > > I also spent a week trying to work out why a customer kernel was > > locking up - only to finally find out that the distro they were > > using set 'panic on opps' - making it almost impossible to find > > out what was happening. Did the machine rebooted before the messages reached console or did it produced crash-dump or frozen? panic() tries relatively hard to flush the messages to the console, see printk_safe_flush_on_panic() and console_flush_on_panic(). It is less aggressive when crashdump is called. It might deadlock in console drivers. Hmm, it might also fail when another CPU is still running and steals console_lock. We might want to disable console_trylock_spinning() if the caller is not panic_cpu. > On 2018/11/26 13:34, Sergey Senozhatsky wrote: > > Or... Instead. > > We can just leave pr_cont() alone for now. And make it possible to > > reconstruct messages - IOW, inject some info to printk messages. We > > do this at Samsung (inject CPU number at the beginning of every > > message. `cat serial.0 | grep "\[1\]"` to grep for all messages from > > CPU1). Probably this would be the simplest thing. > > Yes, I sent a patch which helps reconstructing messages at > http://lkml.kernel.org/r/1543045075-3008-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx . All the buffering approaches have problems that cannot be solved easily. The prefix-based approach looks like the best alternative at the moment. Best Regards, Petr
