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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
