Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Sep 1999 09:15:27 -0400 (EDT)
From:      Rob Garrett <eagle@phc.igs.net>
To:        David Schwartz <davids@webmaster.com>
Cc:        "Brian F. Feldman" <green@FreeBSD.ORG>, Luoqi Chen <luoqi@watermarkgroup.com>, phk@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   RE: Testers please!
Message-ID:  <Pine.BSF.4.10.9909220914240.73656-100000@eagle.phc.igs.net>
In-Reply-To: <000001bf04a9$b50ebf90$021d85d1@youwant.to>

next in thread | previous in thread | raw e-mail | index | archive | help


On Tue, 21 Sep 1999, David Schwartz wrote:

> 
> > One question comes to mind: is there a way that the TSCs could become
> > desynchronized somehow?  Even though all CPUs run at the same frequency,
> > isn't there a strong possibility for slight frequency deviation since
> > we use crystal oscillation instead of a more accurate atomic breakdown
> > for regulation, or am I just smoking crack?
> 
> 	All CPUs should be clocked off of the same frequency multiplier off of the
> same crystal, so it _should_ be impossible for the TSCs to drift apart due
> to that. I guess it might be theoretically possible that something might
> cause the TSCs to drift. Perhaps something crazy with APM and/or SMM. It
> should be tested.
> 
> 	It should also be tested that they begin at the same place. Perhaps
> processors might take different amount of times to 'come out of' reset.
> 
> 	I wouldn't assume anything.
> 
> 	DS
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-smp" in the body of the message
> 
> 
since the spec requires the ap kick the bp's alive, they won't come out of reset 
at the same time. the bp sits and waits, for the ap, to tell it to come alive.

Rob



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.10.9909220914240.73656-100000>