Date: Tue, 16 Jul 2002 15:53:36 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: VOP_GETATTR panic on Alpha Message-ID: <15668.31168.555993.138907@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.20020716150753.jhb@FreeBSD.org> References: <15668.27229.270084.969951@grasshopper.cs.duke.edu> <XFMail.20020716150753.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
> 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..
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15668.31168.555993.138907>