From owner-freebsd-current@FreeBSD.ORG Tue Jun 7 14:20:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4171065670; Tue, 7 Jun 2011 14:20:34 +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 2D4CE8FC16; Tue, 7 Jun 2011 14:20:32 +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 RAA24026; Tue, 07 Jun 2011 17:20:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DEE33AF.5090100@FreeBSD.org> Date: Tue, 07 Jun 2011 17:20:31 +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: "Robert N. M. Watson" References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org> <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org> In-Reply-To: <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:20:34 -0000 on 04/06/2011 12:11 Robert N. M. Watson said the following: > > On 4 Jun 2011, at 09:22, Andriy Gapon wrote: >> commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 >> >> generic_stop_cpus: move timeout detection code from under DIAGNOSTIC >> >> ... and also increase it a bit. IMO it's better to detect and report the >> (rather serious) condition and allow a system to proceed somehow rather than >> be stuck in an endless loop. > > Agreed on detecting and reporting. It would be good to confirm that it works in > practice, however, What is your concern here? :) The code seems rather simple - the loop is no longer infinite. > and also that there are no false positives. I'm not sure > what the best test scenarios are for that. As to the false positives - I think that that can only be verified by practice (very wide testing), because that would greatly depend on hardware. Maybe we should use some time-based approach instead of the iteration count approach or maybe we should calibrate the iteration count based on hardware characteristics... -- Andriy Gapon