On Thu, 5 Apr 2001, Richard Todd wrote:

> I'm running -CURRENT on a dual PII/400 box with 128M of RAM.  The kernel 
> I'm running was built from sources current as of last night (i.e. around
> 9PM CDT Apr 3).  Just now, while listening to streaming audio with xmms, 
> the machine crashed.  It's done that a couple times before, with recent-ish
> kernels while doing streaming audio with xmms, but the other times didn't give
> core dumps with usable backtraces.  *This* time I got a decent backtrace. 
> 
> If I'm reading this backtrace right, the thread handling the sound
> hardware called selwakeup() (frame #19).  This called pfind() (frame
> #18), which tries to lock allproc.  Somewhere in doing this,
> witness_sleep() (frame #15) decides it wants to printf() a message. printf()
> calls down into the tty code, which goes into ptsstart() (frame #9) and the
> pty code (I'm not entirely sure why). This code then tries to do a selwakeup()
> of its own (frame #7) which calls pfind() which tries (again) to lock allproc, 
> leading to the "mutex recursed" panic. 

The TOTTY apparently flag got set by the following code in putchar():

        if ((flags & TOCONS) && tp == NULL && constty) {
                tp = constty;
                flags |= TOTTY;
        }

This caused output to be sent to the terminal `constty' instead of to the
low-level console output routine.  Terminal output is not designed to
work in arbitary contexts, and bad things happened.

This seems to be a very old, very often exercised bug.  printf() always
sets `tp' to NULL, so the output goes to a bad place whenever constty is
non-NULL, but I think this is the normal setup in X.  The terminal output
routines are designed to work in some interrupt contexts, but they depend
on spltty() working to prevent them being reentered.  Even before SMPng,
when spltty() actually worked and there were no locks to hang on, it
was possible for an interrupt not masked by spltty() to occur and reenter
the output routine.

The low-level syscons output routines have similar bugs:
1) They do some locking for screen saver and/or delayed screen update things.
   This causes problems when printf() is called with sched_lock held, e.g.,
   in mi_switch().  The printfs in mi_switch() are ifdefed out to avoid
   this problem.
2) The routines are not reentrant.

Bruce


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

Reply via email to