Date: Sat, 4 Jun 2011 10:11:07 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus Message-ID: <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org> In-Reply-To: <4DE9EB61.3000006@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Jun 2011, at 09:22, Andriy Gapon wrote: > on 03/06/2011 20:57 Robert N. M. Watson said the following: >>=20 >> On 3 Jun 2011, at 16:13, Andriy Gapon wrote: >>=20 >>> 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. >>=20 >> 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? >=20 > Seems to be so as Nathan has also pointed out for PPC. > For this I also plan the following change: >=20 > commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 >=20 > generic_stop_cpus: move timeout detection code from under = DIAGNOSTIC >=20 > ... 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, and also that there are no false positives. = I'm not sure what the best test scenarios are for that. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8AA26086-DA05-4DDA-9973-AE57328E2C81>