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. How can line buffering negatively affect this case? The current thread which triggered an oops will keep calling printk() until that current thread reaches panic(), won't it? The only case where line buffering negatively affects will be that the initial 10 bytes of a critical line failed to reach log_store() because some other thread (not the current thread doing a series of printk()) halted CPUs / reset the whole machine _before_ the initial 10 bytes of a critical line reaches log_store(). 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 .
