From owner-freebsd-current Tue Jul 16 13:13:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC80737B400 for ; Tue, 16 Jul 2002 13:13:34 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 658C643E31 for ; Tue, 16 Jul 2002 13:13:34 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3047 invoked from network); 16 Jul 2002 20:13:32 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jul 2002 20:13:32 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6GKDV054158; Tue, 16 Jul 2002 16:13:31 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15668.31168.555993.138907@grasshopper.cs.duke.edu> Date: Tue, 16 Jul 2002 16:13:32 -0400 (EDT) From: John Baldwin To: Andrew Gallatin Subject: Re: VOP_GETATTR panic on Alpha Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 16-Jul-2002 Andrew Gallatin wrote: > > John Baldwin writes: > > > > > > So its still stuck in msleep. How is it supposed to get back to > > > the panic'ed thread if a system thread wakes up and is not allowed to > > > go back to sleep??? > > > > Hmmmmm. Surprised we don't see this on other archs then (or maybe > > we do...). Probably when we have panic'd (and after we leave the > > debugger and go into boot() or some such) we should take any non-P_SYSTEM > > processes off the run queues and then remove the panicstr checks from > > msleep() and the condition variable wait functions. > > Do you have something like the following psuedo code in mind? > Perhaps placed just prior to the call to boot() in panic()? > > foreach p in (all procs in system) { > if (p == curproc) > continue > if (p->p_flag & P_SYSTEM) > continue; > foreach td in (all threads in p) > if (td->td_state == TDS_RUNQ) > remrunqueue(td); > } > > I assume a panic will IPI other processors and halt them in their > tracks so we don't need to worry too much about locking? Hmm, it doesn't atm. Debugger() does, but panic doesn't. > > Perhaps better is to dink around in choosethread() so that if panicstr > > is set, we throw away any threads get that aren't P_SYSTEM or have the > > TDF_INPANIC flag set. By throw away, I mean that we just ignore any such > > threads and loop if we get one we want to throw away. > > I think that I like your first idea better.. I like my second, it is easier, just add this to choosethread: if (panicstr && ((td->td_proc->p_flag & P_SYSTEM) == 0 && (td->td_flags & TDF_INPANIC) == 0)) goto top; (Do this just before the td_state change and return()). You of couse need to set TDF_INPANIC when setting panicstr. This might mean that we break the restartable panics case. In that case you would just change this so that runq_choose() actually does the work to ignore threads on the run queue instead which eliminates the loop and ugly goto and preserves the runqueue state in the core dump. > Drew -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message