Bruce Evans writes:
> 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
That's the impression I've been getting too ;)
> 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)
I tried adding the panicstr hack to the new KSE code in msleep(), but
it had no noticable affect. I may have done it wrong, as it was a blind
stab w/o any understanding (just skip the KSE code if 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