From owner-freebsd-smp Thu Jun 22 0:57: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2416D37C1D0 for ; Thu, 22 Jun 2000 00:57:02 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id RAA15045; Thu, 22 Jun 2000 17:55:50 +1000 Date: Thu, 22 Jun 2000 17:55:48 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Dillon Cc: Jason Evans , Greg Lehey , Warner Losh , The Hermit Hacker , freebsd-smp@FreeBSD.ORG Subject: Re: SP Patchset #1 up In-Reply-To: <200006211528.IAA94804@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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