From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 08:23:01 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4EC1065675; Sat, 4 Jun 2011 08:23:01 +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 253CF8FC16; Sat, 4 Jun 2011 08:22:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24873; Sat, 04 Jun 2011 11:22:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QSm8I-0004eU-Du; Sat, 04 Jun 2011 11:22:58 +0300 Message-ID: <4DE9EB61.3000006@FreeBSD.org> Date: Sat, 04 Jun 2011 11:22:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 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> In-Reply-To: <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 08:23:01 -0000 on 03/06/2011 20:57 Robert N. M. Watson said the following: > > On 3 Jun 2011, at 16:13, Andriy Gapon wrote: > >> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I >> am very interested to learn about your usecase for it. > > The issue that prompted the sysctl was non-NMI IPIs being used to enter the > debugger or reboot following a core hanging with interrupts disabled. With > the switch to NMI IPIs in some of those circumstances, life is better -- at > least, on hardware that supports non-maskable IPIs. I seem to recall sparc64 > doesn't, however? Seems to be so as Nathan has also pointed out for PPC. For this I also plan the following change: 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. diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c index ae52f4b..4bd766b 100644 --- a/sys/kern/subr_smp.c +++ b/sys/kern/subr_smp.c @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type) /* spin */ cpu_spinwait(); i++; -#ifdef DIAGNOSTIC - if (i == 100000) { + if (i == 100000000) { printf("timeout stopping cpus\n"); break; } -#endif } stopping_cpu = NOCPU; > Not sure about MIPS, etc. Attilio has since significantly > improved our shutdown behaviour -- initially, the switch to NMI IPIs broke > other things (because certain IPIs then improperly preempted threads holding > spinlocks), but that pretty much all seems worked out now. -- Andriy Gapon