On Sat, 6 Jul 2002, Andrew Gallatin wrote:

> OK, current is really confusing me.  When we are panic'ing and syncing
> disks, how are we supposed to come back to the current thread which
> caused the dump after we do an mi_switch() to allow an interrupt
> thread to run?
> The alpha seems to get stuck running various sorts of kernel
> processes, but it never comes back to the one that caused the dump.
> How is this supposed to work?

Accidentally at best.  panic() cannot sleep and should not call
mi_switch(), but sync() wants to do both.  msleep() has a hack that
prevents it from doing very much if (cold || panicstr).  This works
in most cases in FreeBSD-2, but has been rotting as the kernel became
more complicated.  Before KSEII, it was normal for synch() to hit a
deadlock and panic recursively (with no sync() the second time).  KSEII
may have made things worse by putting a lot of code before the hack
in msleep().  The cv_wait() family has the same (cold || panicstr)
hack (including cloned (rotted) comments about doing something to give
interrupts a chance) but no KSE checks before it.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to