Re: [Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 28 Jul 2016 13:12:51 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> Hello Steven,
> 
> On (07/27/16 22:59), Steven Rostedt wrote:
> > > Well, he backed up from that statement later a bit. So when I was
> > > discussing this problem with him at last KS he agreed that making printk
> > > async is the way to go and he specifically dismissed attempts to print
> > > synchronously for a while and fall back to async only later. He just wanted
> > > some way to get things to console synchronously once things go bad (oops,
> > > panic,...) which is discussed elsewhere in this thread.  
> > 
> > Note, my selftests require synchronous printing, so I hope this feature
> > still allows locations to force that without being in oops mode. The
> > tracing selftests can cause triple faults, and seeing where it happened
> > is a must. I already had issues once when printk changed (temporarily)
> > to only dump out lines when a \n was seen. That caused me to think the
> > wrong test was rebooting the box.  
> 
> if you run the tests from user space, then there is a way to change
> printk behavior at will. if from kernel, then... there is no really
> nice way, as of yet.

The tests are run by the kernel at boot up.

> 
> you can do something like (ugly)
> 
> 	console_lock();
> 	test();
> 	console_unlock();
> 
> or change console_loglevel to CONSOLE_LOGLEVEL_MOTORMOUTH temporarily

A temporary force also works.

-- Steve

> 
> 	console_verbose();
> 	test();
> 
> or boot with async printk (if needed) then change to sync mode from
> user space and then start the test...
> 
> by default printk is in sync (old) mode; we don't want to enforce printk
> changes on the systems that have never seen any issues with printk. so unless
> you pass aync printk boot param or change printk to async from user space,
> it must work just as before.