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.
 > Bruce



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

Reply via email to