Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jun 2000 17:55:48 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Jason Evans <jasone@canonware.com>, Greg Lehey <grog@lemis.com>, Warner Losh <imp@village.org>, The Hermit Hacker <scrappy@hub.org>, freebsd-smp@FreeBSD.ORG
Subject:   Re: SP Patchset #1 up
Message-ID:  <Pine.BSF.4.21.0006221737130.418-100000@besplex.bde.org>
In-Reply-To: <200006211528.IAA94804@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Jun 2000, Matthew Dillon wrote:

> :Note that the low level console drivers must not use any locks or switch
> :context, since they need to work in debugger traps which may occur with
> :locks in any state.  Old reentrancy bugs in syscons will probably be
> :more obvious now.  
> 
>     Yah.   That's why I replaced them all with mtx_enter_sched_quick(),
>     which is the closest equivalent to those requirements.  The spl*()
>     calls only work if you are holding GiantMutex, and that obviously
>     is not necessarily the case for the kernel printf().

You now have deadlock when the low level console i/o routines are
reentered for ddb i/o, since task switching is either impossible or
undesireable while ddb is active (it's essentially impossible if ddb
was entered via a breakpoint in the middle of task switching code).

When task switching is possible to avoid deadlock on console i/o
resources, it may still be undesirable.  A printf from a high priority
interrupt task shouldn't have to wait for a printf from a low priority
task to complete.

>     Believe me, I hit those problems early--- when I could ctl-alt-esc
>     into DDB or when a panic would occur and not even print the panic
>     message.  I think I have those cases fixed in patch set #1.

Those are slightly different problems.  spltty() was used for
quasi-locking different things.  It gives deadlock when translated to
real locking.  The things are different so there is no inherent problem.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006221737130.418-100000>