Date: Tue, 07 Jun 2011 17:20:31 +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: <4DEE33AF.5090100@FreeBSD.org> In-Reply-To: <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org> <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DEE33AF.5090100>