[PLUG] local hardware

[Steve Bonds]

On 3/27/06, Steve Bonds wrote:
> On 3/23/06, Steve Bonds wrote:

> I've also run into another, more severe problem with this
> configuration-- also related to the unsynchronized timestamp counters
> (TSCs) found on AMD multiprocessor systems.  My keyboard randomly
> repeats characters under CentOS4, just as described here:
>
> http://kerneltrap.org/node/6258
>
> I've tried the various fixes, some don't apply (not using a USB
> keyboard) and some didn't work ("clock=tsc" on kernel line).  I'll
> keep investigating, but right now I'm not hopeful.

I've found a workaround that seems to work so far, in fact it's the
opposite of the workaround suggested above.  ;-)

I found this detailed description of the AMD TSC issue, straight from
the mouth of an AMD engineer, Rich Brunner:

http://lkml.org/lkml/2005/11/4/173

Some key quotes, just in case the above link goes away since it seems
to be excluded from archive.org:

-----
Current AMD Opteron(tm)  and Athlon(tm)64 processors provide
power  management mechanisms  that independently  adjust the
performance state ("P-state") and power state ("C-state") of
the  processor[1][2];  these  state  changes  can  affect  a
processor  core's  Time   Stamp  Counter  (TSC)  which  some
operating systems  may use as  a part of their  time keeping
algorithms.
-----

-----
Applications  should  avoid   using  the  TSC  directly  for
timekeeping  and instead rely  on the  appropriate operating
system  calls.   Using  the   TSC  directly  means  that  an
application  is not  protected from  TSC-drift and  does not
benefit  from   the  logic   in  the  operating   system  to
work-around it; as a result, applications using TSC directly
could get confused by TSC-drift.
-----

VMware does not follow this advice, it would seem.

-----
TSC  drift  due  to  C1-clock  ramping  can  occur  only  on
8th-generation[8]   AMD    multi-processor   platforms   and
uni-processor  dual-core platforms.   This  drift can  *not*
occur  on  single-processor  single-core platforms.   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.
-----

-----
STPCLK-throttling   is  supported   on   8th-generation  AMD
uni-processor and multi-processor platforms; it is supported
for   7th-generation   processors   only  on   uni-processor
platforms.  STPCLK-throttling  reduces the power consumption
of the  entire platform by  dividing down the clock  rate of
all processor cores in  all processors on the platform.
...
Platform  vendors typically use STPCLK-throttling
as a  safeguard to quickly  cool a platform due  to abnormal
thermal  conditions that  occur on  the platform  or  in the
environment   the  platform   is  in.
...
STPCLK-throttling ramps  up and  down  the clock
grid of all  cores on a processor equally,  therefore it can
not cause TSC drift on a uni-processor platform.
...
STPCLK signaling will  reach processors in a multi-processor
platform at different times,  and each processor can ramp up
and down at different times and different durations than the
others;  therefore TSC  drift can  occur on  such platforms.
-----

-----
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.  Because using  the TSC
for  fast  timer APIs  is  a  desirable  feature that  helps
performance,  AMD  has  defined  a CPUID  feature  bit  that
software   can   test   to   determine   if   the   TSC   is
invariant.
-----

-----
In  general,  it  is  likely  that  end  users  should  only
experience   and  notice   TSC  drift   on  single-processor
dual-core platforms  which do not expose HPET  and which are
running an older operating system  that is using TSC on that
platform. On  such platforms which  run Linux, the  end user
can correct  the problem by specifying  the appropriate boot
option  switch  to  bypass   the  TSC  such  as  "notsc"  or
"clock=pmtmr".    Equivalent  solutions   exist   for  other
operating systems[4].
-----

-----
[1] Throughout this discussion,  a processor is defined as a
    physical  socketed chip package  containing one  or more
    on-die CPU cores;  a processor plugs into a  socket on a
    platform motherboard.
[2] These are described  in the "BIOS and Kernel Developer's
    Guide  for   AMD  Athlon(tm)  64   and  AMD  Opteron(tm)
    Processors", Publication 26094
[3] TSC drift occurs when the computed (expected) difference
    between the  TSCs of two  cores is no longer  a constant
    value but  varies by a  significant amount to  the shock
    and surprise of the operating system.
[4] 32-bit  Windows XP SP2,  64-bit Windows XP,  and Windows
    2003  SP1  provide   the  "/usepmtimer"  switch  in  the
    boot.ini to  override using the  TSC on single-processor
    dual-core platforms; these operating systems do not rely
    upon TSC on multi-processor platforms.
[5] HPET  High Precision  Event  Timer  is  defined in  the
    "Advanced    Configuration     and    Power    Interface
    Specification, Revision 3.0"
[6] ACPI Power Management  Timer is defined in the "Advanced
    Configuration   and   Power   Interface   Specification,
    Revision 3.0"
[7] AMD's 7th  generation  processors return  a CPUID  base
    family value of '7'. These include AMD Athlon, AthlonXP,
    AthlonMP, and Duron.
[8] AMD's  8th generation  processors  return an  effective
    CPUID family of '0x0F'. These include AMD Opteron,
    Athlon64, and Turion.
-----

The suggested "clock=pmtmr" kernel option seems to have solved the
frequent keyboard repeat problem for me.  Note that this is an
SMP-specific issue, so Galen Seitz's keyboard repeat problem is
something different.

I may still have an infrequent problem, but at least the system is
usable now.  With the keyboard going nuts every 30-60 seconds or so,
it really wasn't.

  -- Steve