TSC is initialized to 0 at hardware reset, which should happen to all CPUs
at the same time (invalid assumption?), in another words, all TSCs should be
automatically synchronized.
They are not. The PLL is local to each cpu and every single
clock-stop/start event has then inching away from
In message [EMAIL PROTECTED], Luoqi Chen writes:
people have found sufficiently many cases where the counters are
not in sync after the BIOS is done.
I would really like to know how they managed to read the TSCs simultaneously,
or they resorted to some kind of statistical means (which I
...
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
In message [EMAIL PROTECTED], Jim Bryant writes:
since there is only a single master clock oscillator, there really
should be no frequency difference between CPUs.
As long it runs constantly: yes. As soon as you have clock-stop
events you will have different resync times for the on-chip PLLs.
If you have a PIIX4 based SMP system and run current, could you
please try out this patch:
http://phk.freebsd.dk/piix/
I'm very interested in hearing if there are any measurable difference
apart from clock granularity being 3 times better.
--
Poul-Henning Kamp
On Tue, 21 Sep 1999, Luoqi Chen wrote:
This reminds me about the usage of TSC counter on SMP. First even though
we don't use TSC for time keeping on SMP, the TSC frequency from calibration
is still valid (at least for BSP), and we can show it in the cpu identification
message. Second, the
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
Ok, noted. I changed to to fail the probe but still use the hardware.
Poul-Henning
In message [EMAIL PROTECTED], Peter Wemm writes
:
Poul-Henning Kamp wrote:
If you have a PIIX4 based SMP system and run current, could you
please try out this patch:
http://phk.freebsd.dk/piix/
Poul-Henning Kamp wrote:
Ok, noted. I changed to to fail the probe but still use the hardware.
If intpm is probed first (the smbus driver), your probe won't even get
called. I think we need an early quirks or hooks handler in the pci probes
to handle stuff like this. For example, we have
In message [EMAIL PROTECTED], Peter Wemm writes
:
Poul-Henning Kamp wrote:
Ok, noted. I changed to to fail the probe but still use the hardware.
If intpm is probed first (the smbus driver), your probe won't even get
called. I think we need an early quirks or hooks handler in the pci probes
On Sun, 19 Sep 1999, Poul-Henning Kamp wrote:
If you have a PIIX4 based SMP system and run current, could you
please try out this patch:
http://phk.freebsd.dk/piix/
I'm very interested in hearing if there are any measurable difference
apart from clock granularity being 3 times
11 matches
Mail list logo
