From owner-freebsd-smp Fri Jun 23 13: 7:40 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id AA53F37B639 for ; Fri, 23 Jun 2000 13:07:33 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 14603 invoked from network); 23 Jun 2000 20:07:29 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 23 Jun 2000 20:07:29 -0000 Date: Sat, 24 Jun 2000 06:07:26 +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: <200006231743.KAA11163@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 Fri, 23 Jun 2000, Matthew Dillon wrote: > :> SchedMutex is never invalid. No mutex is ever 'invalid'... they are > :> ... > :>From your patches for exception.s: > :>... > You mean i386/i386/swtch.s > ... > 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 solve this without the CLI/STI by releasing the SchedMutex > entirely, changing curproc, and then regaining SchedMutex. I personally > do not like that idea but it would be more 'correct', and it would not > have the lockup problem if a DDB trap or NMI occured on the current cpu > at just that point. What should happen is for the low level console driver to be reentrant, like the sio driver attempts to be. Then locking would only be cosmetic. It might prevent garbling of single characters, but since it is per-char it won't prevent interleaving of output. I'm not sure what exactly what reentrancy means for the SMP case. For debugger i/o, it is the same as for the UP case since all cpus except the one running the debugger must be stopped or spinning. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message