From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754851AbdDLSn0 (ORCPT ); Wed, 12 Apr 2017 14:43:26 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:48694 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752401AbdDLSnX (ORCPT ); Wed, 12 Apr 2017 14:43:23 -0400 Date: Wed, 12 Apr 2017 20:43:20 +0200 From: Pavel Machek To: Sergey Senozhatsky Cc: Petr Mladek , Jan Kara , "Eric W. Biederman" , Ye Xiaolong , Steven Rostedt , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , Greg Kroah-Hartman , Jiri Slaby , Len Brown , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Message-ID: <20170412184320.GC18640@amd> References: <20170407074634.GB1091@jagdpanzerIV.localdomain> <20170407081449.GA12859@amd> <20170407121021.GA379@jagdpanzerIV.localdomain> <20170407124455.GC4756@amd> <20170407151306.GA384@tigerII.localdomain> <20170409101230.GB27363@amd> <20170410045339.GB2793@jagdpanzerIV.localdomain> <20170410184858.GA24226@amd> <20170411014635.GA3836@jagdpanzerIV.localdomain> <20170411161953.GA447@tigerII.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: <20170411161953.GA447@tigerII.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed 2017-04-12 01:19:53, Sergey Senozhatsky wrote: > On (04/11/17 10:46), Sergey Senozhatsky wrote: > > On (04/10/17 20:48), Pavel Machek wrote: > > [..] > > > > but, once again, I see your point. > > >=20 > > > Good. Does that mean that the next version of patches will work ok in > > > that case? > >=20 > > yes. >=20 > ok... so I'm looking at something like below right now. > not really tested yet. >=20 > I put some comments into the code. >=20 > it does offloading after X printed lines by the same process. > if we reschedule, then the counter resets. which is probably OK, > we don't really want any process, except for printk_kthread, to > stay in console_unlock() forever. "number of lines printed" is > probably easier to understand (easily converted to the number of > pageup/pagedown you need to press, terminal buffer history size, > etc.) than seconds we spent on printing (which doesn't even > correspond to messages' timestamps in general case). Design looks good to me... certainly better than previous version :-). =09 > 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?=20 Thanks, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljudUgACgkQMOfwapXb+vINVgCgmUT4r4tagfh1MSuiwICcNzOK bqcAnRuEJOB/BcGX3idNMojcvxKlVWV/ =Swzl -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU--