[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170413043410.GA13708@jagdpanzerIV.localdomain>
Date: Thu, 13 Apr 2017 13:34:10 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>, Jan Kara <jack@...e.cz>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Ye Xiaolong <xiaolong.ye@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, Len Brown <len.brown@...el.com>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [printk] fbc14616f4:
BUG:kernel_reboot-without-warning_in_test_stage
On (04/12/17 20:43), Pavel Machek wrote:
[..]
> > when the limit of "number of lines printed" is 0, then no
> > offloading takes place.
>
> And with "number of lines printed" set to 999999, it will get us
> previous behaviour, right?
`atomic_print_limit' set to zero disables offloading explicitly.
at the same time, an unreasonably high `atomic_print_limit' value
makes offloading less possible and starting from some value,
basically, disables it implicitly.
-ss
Powered by blists - more mailing lists