From owner-freebsd-smp Fri Jun 23 14: 7:57 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 7F03037B777 for ; Fri, 23 Jun 2000 14:07:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA11962; Fri, 23 Jun 2000 14:07:47 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Jun 2000 14:07:47 -0700 (PDT) From: Matthew Dillon Message-Id: <200006232107.OAA11962@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 :> ... :> If a debugger trap were to occur on the current cpu at just point, it :> would indeed lead to a lockup. You are absolutely correct. So maybe :> the comment should read: don't create any break points in between the :> setting of curproc and the fixup of SchedMutex! : :Also: don't trace into the context switching code. This is very inconvenient. :I've often typed 'n' in the debugger and then #$&* when the system crashes :because ddb traced into nonreentrant code. (This happened yesterday when :I tried 'n' to get a count of the number of instructions taken by a vmware :ioctl.) We can make tracing through the context switch code work. Hmm. We have two choices: either make the context switch code trace-safe (by actually unlocking SchedMutex when changing curproc), or make the DDB trap save/override and restore the SchedMutex state, which is what it did before. Sorta. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message