Date: Sat, 04 Jun 2011 11:22:57 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus Message-ID: <4DE9EB61.3000006@FreeBSD.org> In-Reply-To: <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE9EB61.3000006>