Date: Thu, 1 Dec 2011 13:49:50 -0500 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic Message-ID: <201112011349.50502.jhb@freebsd.org> In-Reply-To: <4ED7B25E.8070002@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111211132.42119.jhb@freebsd.org> <4ED7B25E.8070002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote: > > [cc list trimmed] > > on 21/11/2011 18:32 John Baldwin said the following: > > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: > >> on 17/11/2011 23:38 John Baldwin said the following: > >>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > >>>> Hmmm, you could also make critical_exit() not perform deferred preemptions > >>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the > >>>> preemption "work" when resuming from the debugger? > > > Just to clarify, probably you are actually suggesting to not perform deferred > preemptions if kdb_active == TRUE. Because that's where we get the recursion (via > kdb_switch). > > I think that if we get into the mi_switch in a state where !kdb_active && > SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? > > [the following is preserved for context] Hmmm. I'd be tempted to just ignore pending preemptions anytime SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being in the debugger (e.g. panic), I'd rather make a best effort at getting a dump than panic again. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112011349.50502.jhb>