cvs commit: src/sys/kern subr_sleepqueue.c

[Bruce Evans]

On Tue, 2 Mar 2004, John Baldwin wrote:

> On Tuesday 02 March 2004 04:38 pm, Dag-Erling Sm=F8rgrav wrote:
> > I believe you've missed at least one other abnormal case: either
> > linux_rt_sigsuspend used to trigger the "mismatched locks" warning,
> > and now just gives me a panic.  To top it all off, the box freezes
> > right after the Debugger("panic") line, without dropping to ddb.
>
> I never saw that case and this is the first I've heard of it.  ddb tends =
to
> freeze when you enter it holding a spin lock.  Do you have any log messag=
es
> from the mis-matched locks for msleep?

ddb doesn't tend to freeze for me, perhaps because I rarely use witness
and the most common problem is there.  However, we seem to have some
foot-shooting in Debugger().  The locking there is mostly wrong, and
just calling printf() there is dangerous.  I think it can hang due to
bugs in console drivers.  E.g., for syscons:
- syscons sometimes hangs if it is called with sched_lock held, since
  it calls wakeup() which acquires sched_lock.  See an XXX comment in
  sc_switch_scr().
- this problem has been worked around for printfs from the debugger
  proper.  See the same XXX comment.  The workaround seems to be
  adequate.
- however, Debugger() calls printf before it enters debugger context,
  so the workaround doesn't apply.

Direct entry to the debugger using breakpoint() should work better, but
there are some problematic messages there too (messages before entering
and after leaving debugger context).  Fortunately, these are rarely
printed unless VERBOSE_CPUSTOP_ON_DDBBREAK is enabled and the system is
SMP.

Bruce