On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
What if somebody were to port the linux TSC syncing code, and use it
to decide whether or not set kern.timecounter.smp_tsc=1? Would you
object to that?
Yes, I would object to that.
Even to this day new CPU chips come out where TSC has flaws that
prevent it from being used as timecounter, and we do not have (NDA)
access to the data that would allow us to build a list of safe
hardware.
Um, I have already pointed out that NDAs are not necessary.
They (and staic lists) are also not sufficient. E.g., on my A7V-266E
system (AXP on KT266A motherboard), the following breaks the TSC for
timecounting:
# Athlon idle hack for my KT266A.
pciconf -w -b pci0:0:0 0x92 0xf9 # 79 -> f9
pciconf -w -b pci0:0:0 0x95 0x1a # 18 -> 1a
Enough is freely disclosed, and the hardware is perfectly safe, but
only if it configured without the (idle == really idle) setting which
is set by the above hack but not by the BIOS. This setting reduces
the temperature of a mostly-idle AXP system by about 10 degrees C.
IIRC, the (idle == really idle) feature is entirely in the CPU and the
hack just changes the state of the pins that control this feature.
The breakage is much the same for 2 different generations of AXPs (a
'1600 and a '2200) -- it causes jumps in the milliseconds per second
range where without it there is only temperature-related drift in the
nanoseconds per second range. I suspect all AXPs have this feature
so they all have a potentially-broken TSC timecounter.
Bruce
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
