Date: Fri, 2 Dec 2011 07:30:27 -0800 From: mdf@FreeBSD.org To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic Message-ID: <CAMBSHm_Cw1dSfoRVBo0bw_jAtB3Xrw0s%2BDZfFGKyCaXJS6F2CQ@mail.gmail.com> In-Reply-To: <4ED8A306.9020801@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon <avg@freebsd.org> wrote: > on 02/12/2011 06:36 John Baldwin said the following: >> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when= kdb was >> active). =A0But I think these two changes should cover critical_exit() o= k. >> > > I attempted to start a discussion about this a few times already :-) > Should we treat kdb context the same as SCHEDULER_STOPPED context (in the > current definition) ? =A0That is, skip all locks in the same fashion? > There are pros and contras. Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I can no longer remember...) when it enters? If so, then I'd say whether it enters via sysctl or panic doesn't matter. It's in a special environment where nothing else is running, which is what is needed for proper exploration of the machine (via breakpoint, for debugging a hang, etc). Maybe the question is, why wouldn't SCHEDULER_STOPPED be true regardless of how kdb is entered? Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm_Cw1dSfoRVBo0bw_jAtB3Xrw0s%2BDZfFGKyCaXJS6F2CQ>