From owner-svn-src-user@FreeBSD.ORG Thu May 26 16:05:14 2011 Return-Path: Delivered-To: svn-src-user@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A440106566C; Thu, 26 May 2011 16:05:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A8BF58FC13; Thu, 26 May 2011 16:05:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA22972; Thu, 26 May 2011 19:05:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE7A36.2050104@FreeBSD.org> Date: Thu, 26 May 2011 19:05:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <201105181508.p4IF8UoS096841@svn.freebsd.org> <20110518182441.GB2273@garage.freebsd.pl> <4DD4243C.4070301@FreeBSD.org> <4DDD13F9.5040800@FreeBSD.org> <4DDE7555.7090500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Attilio Rao , src-committers@FreeBSD.org, Pawel Jakub Dawidek , svn-src-user@FreeBSD.org Subject: Re: svn commit: r222060 - in user/avg/xcpu/sys: kern sys X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:05:14 -0000 on 26/05/2011 18:46 mdf@FreeBSD.org said the following: > A per-thread flag is needed as long as other CPUs can be running or > even just the scheduler on the remaining CPU. So I would thing that > flag needs to be checked until the system has been massaged to the > state you describe above. I am not sure that I understand your reasoning if you mean that the flag needs to be checked in TD_IS_INPANIC. That is, right now there is no TD_IS_INPANIC and things work after panic to a certain degree. I do not intend to improve that degree and just want to keep an option to revert to the current state of matters. When TD_IS_INPANIC is introduced and stop_cpus_on_panic==1, then there will be only one thread left running after panic, that will be the thread that called panic, checking TDF_INPANIC just doesn't add anything. -- Andriy Gapon