Is there a clock skew problem with AMD rev. F Opterons running Red Hat Enterprise Linux 3 i386 kernel?

Release Found: Red Hat Enterprise Linux 3.8

TSC drift due to C1-clock ramping can only occur on K8 AMD multi-processor platforms and uni-processor dual-core platforms as they do not provide frequency independent TSC. It is generally noticeable only when the operating system uses the TSC as either the only source of time or as a fast timer to interpolate between periodic timer interrupts.

As a result when the OS makes gettimeofday queries with TSC as the time source, it has been found that time appears to fluctuate and go backwards. This can cause several problems on a system including, a single key press resulting in multiple keystrokes displayed on the console, and the cumulative output of gettimeofday shows time going backwards.

This problem was reported against Red Hat's Red Hat Enterprise Linux 3.8 i386 distribution. This distribution has HPET and TSC as the time source but does not have PM timer implementation. TSC drift is usually seen in single processor dual core platforms which do not expose HPET and as a result the default time source in the Red Hat Enterprise Linux 3 kernel is TSC.

The solution to the problem is to disable C1-clock ramping. While C1-clock ramping can be controlled via BIOS, AMD and Red Hat recommending a patch which is included in the 2.4.21-47.0.1.EL kernel via RHSA-2006:0710 ( https://rhn.redhat.com/rhn/errata/details/Details.do?eid=5050 . The patch to fix the TSC problem disables C1-clock ramping and is done by clearing PMM7 bits on each core's Miscellaneous Control device, which is configurable via PCI space.

Future AMD processors will provide a TSC that is P-state and C-State invariant and unaffected by STPCLK-throttling. This will make the TSC immune to drift.