From owner-freebsd-smp Thu Jun 22 8:58:50 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C595137C326 for ; Thu, 22 Jun 2000 08:58:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA03062; Thu, 22 Jun 2000 08:58:40 -0700 (PDT) (envelope-from dillon) Date: Thu, 22 Jun 2000 08:58:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200006221558.IAA03062@apollo.backplane.com> To: Bruce Evans Cc: Jason Evans , Greg Lehey , Warner Losh , The Hermit Hacker , freebsd-smp@FreeBSD.ORG Subject: Re: SP Patchset #1 up References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> :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. I don't follow. Why do I have a deadlock? This is SchedMutex I'm talking about here, not GiantMutex. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message