Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Jun 2000 06:07:26 +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.0006240527220.686-100000@besplex.bde.org>
In-Reply-To: <200006231743.KAA11163@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




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